idnits 2.17.1 draft-ietf-sieve-notify-03.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 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** 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 (June 23, 2006) is 6489 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) == Missing Reference: 'MODIFIER' is mentioned on line 368, but not defined ** 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 (~~), 3 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: December 25, 2006 B. Leiba, Ed. 5 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 Mirapoint Inc. 9 June 23, 2006 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-03 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 December 25, 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 ToDo 58 o Change tagged :method to the positional parameter? 60 Changes since draft-ietf-sieve-notify-02 62 o Added :from tagged argument. 64 o Added Extract_text action, which allows to extract content of the 65 first text/* part. 67 o Added back the ":options" parameter to the notify action. 69 o Added new section talking about requirements on notification 70 method specs. 72 o Added more examples. 74 Changes since draft-ietf-sieve-notify-00 76 o Updated references, etc. 78 o Added IANA considerations section. 80 o Removed denotify action. 82 o Updated examples to use the variables extension. 84 o Replaced notification method with URI. 86 o Removed text suggesting that this extension can be used to track 87 all Sieve actions taken. 89 o Changed priority to be a string. 91 o Added text about URI verification. 93 o Clarified that a notification method is allowed to perform 94 adaptation of notification context (e.g. truncation, charset 95 conversion, etc.). These adaptations must be documented in a 96 document describing the notification method. 98 o Clarified that notify is compatible with all existing actions. 100 o Removed the :id parameter to the notify action. 102 o Added valid_notif_method test that allows to test if an 103 notification method (URI) is supported. 105 o Added a new capability response to ManageSieve that allows to 106 report supported notification types. 108 Table of Contents 110 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 111 1.1. Conventions used in this document . . . . . . . . . . . . . 5 113 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 5 115 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 5 116 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 5 117 3.2. Notify tag ":method" . . . . . . . . . . . . . . . . . . . . 5 118 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 6 119 3.4. Notify tag ":priority" . . . . . . . . . . . . . . . . . . . 6 120 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 7 121 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 7 122 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 123 3.8. Requirements on notification methods specifications . . . . 9 125 4. Extract_text Action . . . . . . . . . . . . . . . . . . . . 10 127 5. Test valid_notif_method . . . . . . . . . . . . . . . . . . 11 129 6. Interactions with Other Sieve Actions . . . . . . . . . . . 11 131 7. Security Considerations . . . . . . . . . . . . . . . . . . 11 133 8. Extensions to ManageSieve protocol . . . . . . . . . . . . . 12 135 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 137 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 139 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 140 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 141 11.2. Informative References . . . . . . . . . . . . . . . . . . . 13 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 143 Intellectual Property and Copyright Statements . . . . . . . 15 145 1. Introduction 147 This is an extension to the Sieve language defined by [Sieve] for 148 providing instant notifications. It defines the new action "notify". 150 This document does not dictate the notification method used. 151 Examples of possible notification methods are Zephyr and Jabber. The 152 available methods shall be site-defined. 154 1.1. Conventions used in this document 156 Conventions for notations are as in [Sieve] section 1.1, including 157 the use of [ABNF]. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [Kwds]. 163 2. Capability Identifier 165 The capability string associated with the extension defined in this 166 document is "notify". 168 3. Notify Action 170 3.1. Notify Action Syntax and Semantics 172 Usage: notify [":method" string] 173 [":from" string] 174 [":priority" <"1" / "2" / "3">] 175 [":options" 1*(string-list / number)] 176 [":message" string] 178 The Notify action specifies that a notification should be sent to the 179 user. The format of the notification is implementation-defined and 180 is also affected by the notification method used (see Section 3.2). 181 However, all content specified in the :message parameter SHOULD be 182 included. 184 3.2. Notify tag ":method" 186 The :method tag identifies the notification method that will be used; 187 it is a URI. For example, the notification method can be an SMS URI 188 [SMS-URI] containing a phone number, or an XMPP [XMPP] URI containing 189 a Jabber identifier [XMPP-URI]. If the :method tag is not specified, 190 a default implementation-defined notification method is used, and if 191 there is no default method defined, the notification is ignored. 192 Implementations MUST NOT generate an error condition for lack of a 193 default notification method, and execution of the script MUST 194 continue. 196 The supported URI values will be site-specific. If an URI schema is 197 specified that the implementation does not support, the notification 198 MUST cause an error condition. Sieve scripts can check the supported 199 methods using the "valid_notif_method" test to be sure that they only 200 use supported ones, to avoid such error conditions. If the :method 201 tag contains a supported URI schema, then the URI MUST be checked for 202 syntactic validity. An invalid URI syntax or an unsupported URI 203 extension MUST cause an error. An implementation MAY enforce other 204 semantic restrictions on URIs -- for example an SMS URI can only 205 contain phone numbers in a particular geographical region. Violation 206 of such semantic restrictions MUST be treated as an error. 207 [[Barry 1: "MUST" seems silly here, since the whole sentence is a 208 "MAY".]] 210 3.3. Notify tag ":from" 212 A ":from" parameter may be used to specify a notification method 213 specific author of the notification. Implementations SHOULD check 214 the syntax according to the notification method specification and 215 generate an error when a syntactically invalid ":from" parameter is 216 specified. 218 3.4. Notify tag ":priority" 220 The :priority tag specifies the importance of the notification. The 221 :priority tag is followed by a numeric value represented as a string: 222 "1" (high importance), "2" (normal importance), and "3" (low 223 importance). If no priority is given, a default priority of "2" 224 SHOULD be assumed. Some notification methods allow users to specify 225 their state of activity (for example "busy" or "away from keyboard"). 226 If the notification method provides this information it SHOULD be 227 used to selectively send notifications. If, for example, the user 228 marks herself as "busy", a notification method can require that a 229 notification with a priority of "3" is not to be sent, however the 230 user should be notified of a higher priority notifications. If the 231 notification method allows users to filter messages based upon 232 certain parameters in the message, users SHOULD be able to filter 233 based upon priority. If the notification method does not support 234 priority, then this parameter MUST be ignored. 235 [[Alexey 1: Should we keep using "high", "normal" and "low" instead? 236 Numbers are easier to compare with comparators.]] 237 [[Barry 3.5: Why do we call this "priority", and then explain it as 238 "importance"? Shouldn't we just call it "importance"?]] 240 3.5. Notify tag ":options" 242 The :options tag is used to send additional parameters to the 243 notification method. Interpretation of :options is method-specific. 244 [[Alexey 2: Do we need IANA registry for this?]] 246 3.6. Notify tag ":message" 248 The :message tag specifies the message data to be included in the 249 notification. The entirety of the string SHOULD be sent but 250 implementations MAY shorten the message for technical or aesthetic 251 reasons. If the message parameter is absent, a default message 252 containing the value of the From header field [[Alexey 3: Align with 253 usage of :from]] and the value of the Subject header field will be 254 used. Note that the notification method (the ":method" tag) may 255 affect how this information is formatted. 257 The implementation of a notification method MAY modify the final 258 notification text -- for example, truncating it if it exceeds a 259 length limit, or modifying characters that can not be represented in 260 the target character set. Allowed modifications should be documented 261 in a standards-track or informational document. 263 In order to construct more complex messages the notify extension can 264 be used together with the Sieve variables extension [Variables], as 265 shown in the examples below. 267 3.7. Examples 268 Example 1: 269 require ["notify", "fileinto", "variables"]; 271 if header :contains "from" "boss@example.org" { 272 notify :priority "1" 273 :message "This is probably very important"; 274 # Don't send any further notifications 275 stop; 276 } 278 if header :contains "to" "sievemailinglist@example.org" { 279 # :matches is used to get the value of the Subject header 280 if header :matches "Subject" "*" { 281 set "subject" "${1}"; 282 } 284 # :matches is used to get the value of the From header 285 if header :matches "From" "*" { 286 set "from" "${1}"; 287 } 289 notify :priority "3" 290 :message "[SIEVE] ${from}: ${subject}"; 291 fileinto "INBOX.sieve"; 292 } 294 Example 2: 295 require ["notify", "fileinto", "variables", "envelope"]; 297 if header :matches "from" "*@*.example.org" { 298 # :matches is used to get the MAIL FROM address 299 if envelope :all :matches "from" "*" { 300 set "env_from" " [really: ${1}]"; 301 } 303 # :matches is used to get the value of the Subject header 304 if header :matches "Subject" "*" { 305 set "subject" "${1}"; 306 } 308 # :matches is used to get the address from the From header 309 if address :matches :all "from" "*" { 310 set "from_addr" "${1}"; 311 } 313 notify :message "${from_addr}${env_from}: ${subject}"; 314 } 316 Example 3: 317 require ["notify", "variables"]; 319 set "notif_method" 320 "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE"; 322 if header :contains "subject" "Your dog" { 323 set "notif_method" "sms:+14085551212"; 324 } 326 if header :contains "to" "sievemailinglist@example.org" { 327 set "notif_method" ""; 328 } 330 if not string :is "${notif_method}" "" { 331 notify :method "${notif_method}"; 332 } 334 if header :contains "from" "boss@example.org" { 335 # :matches is used to get the value of the Subject header 336 if header :matches "Subject" "*" { 337 set "subject" "${1}"; 338 } 340 # don't need high priority notification for 341 # a 'for your information' 342 if not header :contains "subject" "FYI:" { 343 notify :method "sms:+14085551212" 344 :priority "1" :message "BOSS: ${subject}"; 345 } 346 } 348 [[anchor2: Make sure that the XMPP notification syntax is correct.]] 350 3.8. Requirements on notification methods specifications 352 This section describes requirements on a document describing a Sieve 353 notification method. [[Alexey 4: The whole section is very raw and 354 needs more work.]] 356 A notification method MAY ignore parameters specified in the Notify 357 action. 359 It is RECOMMENDED that a timestamp be included in the notification. 361 Implementations SHOULD NOT include extraneous information. 363 If there are errors sending the notification, the Sieve interpreter 364 SHOULD ignore the notification and not retry indefinitely. 366 4. Extract_text Action 368 Usage: extract_text [MODIFIER] [":first" number] 369 371 The Extract_text action stores at most :first bytes of the first 372 text/* part in the variable identified by varname. If the :first 373 parameter is not present, the whole content of the first text/* part 374 is stored. If the message being processed doesn't contain any text/* 375 part, the action will set the variable identified by varname to empty 376 string. [[Alexey 5: Do we need to be more specific about what "the 377 first text part" means?]] 379 Modifiers are applied on the extracted text before it is stored in 380 the variable. See [Variables] for details. 382 Note that this action is only available when the Sieve script 383 specifies both "variables" [Variables] and "notify" capabilities in 384 the require statements. 386 Example 4: 387 require ["notify", "variables"]; 389 if header :contains "from" "boss@example.org" { 390 # :matches is used to get the value of the Subject header 391 if header :matches "Subject" "*" { 392 set "subject" "${1}"; 393 } 395 # extract the first 100 bytes of the first text/* part 396 extract_text :first 100 "msgcontent"; 398 # don't need high priority notification for 399 # a 'for your information' 400 if not header :contains "subject" "FYI:" { 401 notify :method "sms:+14085551212" 402 :priority "1" :message 403 "BOSS: ${subject}; ${msgcontent}"; 404 } 405 } 407 5. Test valid_notif_method 409 Usage: valid_notif_method 411 The "valid_notif_method" test is true if the notification methods 412 listed in the notification-uris argument are supported and they are 413 syntactically and semantically (including implementation-specific 414 semantic restrictions) valid. This test MUST perform exactly the 415 same validation as would be performed on the ":method" parameter of 416 the "notify" action. 418 All of the listed notification methods must be supported and valid or 419 the test is false. 421 Example 5: 422 if not valid_notif_method ["mailto:", 423 "http://gw.example.net/notify?test"] { 424 stop; 425 } 427 6. Interactions with Other Sieve Actions 429 The notify action is compatible with all other actions, and does not 430 affect the operation of other actions. In particular, the notify 431 action MUST NOT cancel the implicit keep. 433 Multiple executed notify actions are allowed. 435 7. Security Considerations 437 Security considerations are discussed in [Sieve]. Additionally, 438 implementations must be careful to follow the security considerations 439 of the specific notification methods. 441 The notify action is potentially very dangerous. The path the 442 notification takes through the network may not be secure. An error 443 in the options string may cause the message to be transmitted to 444 someone it was not intended for, or may expose information to 445 eavesdroppers. 447 Just because a notification is received doesn't mean it was sent by 448 the Sieve implementation. It might be possible to forge 449 notifications with some notification methods. 451 8. Extensions to ManageSieve protocol 453 A ManageSieve [ManageSieve] server that supports the "notify" 454 extension MUST advertise the NOTIFY capability, that has a single 455 mandatory parameter. The parameter is a string containing space 456 separated list of URI schema parts for supported nofication methods. 458 Example: 459 S: "NOTIFY" "xmpp mailto" 461 9. IANA Considerations 463 The following template specifies the IANA registration of the notify 464 Sieve extension specified in this document: 466 To: iana@iana.org 467 Subject: Registration of new Sieve extension 468 Capability name: notify 469 Capability keyword: notify 470 Capability arguments: N/A 471 Standards Track/IESG-approved experimental RFC number: this RFC 472 Person and email address to contact for further information: 473 Alexey Melnikov 475 This information should be added to the list of sieve extensions 476 given on http://www.iana.org/assignments/sieve-extensions. 478 10. Acknowledgements 480 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 481 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 482 Mallett and Ned Freed for help with this document. 484 11. References 486 11.1. Normative References 488 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 489 Specifications: ABNF", RFC 4234, October 2005. 491 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", RFC 2119, March 1997. 494 [ManageSieve] 495 Martin, T. and A. Melnikov, "A Protocol for Remotely 496 Managing Sieve Scripts", work in 497 progress, draft-martin-managesieve, February 2006. 499 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 500 Language", work in progress, draft-ietf-sieve-3028bis, 501 July 2005. 503 [Variables] 504 Homme, K., "Sieve Extension: Variables", work in 505 progress, draft-ietf-sieve-variables, October 2005. 507 11.2. Informative References 509 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 510 Message Service", work in progress, draft-wilde-sms-uri, 511 August 2005. 513 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 514 Protocol (XMPP): Core", RFC 3920, October 2004. 516 [XMPP-URI] 517 Saint-Andre, P., "Internationalized Resource Identifiers 518 (IRIs) and Uniform Resource Identifiers (URIs) for the 519 Extensible Messaging and Presence Protocol (XMPP)", work 520 in progress, draft-saintandre-xmpp-iri, September 2005. 522 Authors' Addresses 524 Alexey Melnikov (editor) 525 Isode Limited 526 5 Castle Business Village 527 36 Station Road 528 Hampton, Middlesex TW12 2BX 529 UK 531 Email: Alexey.Melnikov@isode.com 533 Barry Leiba (editor) 534 IBM T.J. Watson Research Center 535 19 Skyline Drive 536 Hawthorne, NY 10532 537 US 539 Phone: +1 914 784 7941 540 Email: leiba@watson.ibm.com 542 Wolfgang Segmuller 543 IBM T.J. Watson Research Center 544 19 Skyline Drive 545 Hawthorne, NY 10532 546 US 548 Phone: +1 914 784 7408 549 Email: werewolf@us.ibm.com 551 Tim Martin 552 Mirapoint Inc. 553 909 Hermosa Court 554 Sunnyvale, CA 94085 555 US 557 Phone: +1 409 720 3835 558 Email: tmartin@mirapoint.com 560 Intellectual Property Statement 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Disclaimer of Validity 586 This document and the information contained herein are provided on an 587 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 588 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 589 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 590 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 591 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 592 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 594 Copyright Statement 596 Copyright (C) The Internet Society (2006). This document is subject 597 to the rights, licenses and restrictions contained in BCP 78, and 598 except as set forth therein, the authors retain all their rights. 600 Acknowledgment 602 Funding for the RFC Editor function is currently provided by the 603 Internet Society.