idnits 2.17.1 draft-ietf-sieve-notify-10.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, updated by RFC 4748 on line 823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 847. 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 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 (November 7, 2007) is 6013 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: 'COMPARATOR' is mentioned on line 524, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 524, 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: 2 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 Intended status: Standards Track B. Leiba, Ed. 5 Expires: May 10, 2008 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 November 7, 2007 11 SIEVE Email Filtering: Notifications 12 draft-ietf-sieve-notify-10 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 May 10, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 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 it is expected that using existing instant messaging 51 infrastructure such as XMPP, or SMS messages will be popular. This 52 draft describes an extension to the Sieve mail filtering language 53 that allows users to give specific rules for how and when 54 notifications should be sent. 56 Changes since draft-ietf-sieve-notify-09 58 o Extended requirements for avoiding loops and amplification 59 attacks. 61 o Other minor editorial changes as per AD's (Lisa) review. 63 Changes since draft-ietf-sieve-notify-08 65 o Added missing IANA registry for notification methods. 67 Changes since draft-ietf-sieve-notify-07 69 o Added a new "set" modifier for URL percent-encoding. 71 o Clarified that notification methods must address notification 72 loops. 74 o Added an implementation consideration for implementations that use 75 URIs internally. 77 Changes since draft-ietf-sieve-notify-06 79 o Remove extract_text. The WG consensus was to move it to another 80 document, such as Sieve MIME loops. 82 o Deleted markers for open issues from the document. 84 o Clarified that a notification mechanism can treat some URI 85 parameters as an error. 87 o Added notify_method_capability test and example. 89 o Minor corrections to the IANA registration as a result of other 90 changes. 92 Changes since draft-ietf-sieve-notify-05 94 o Fixed XMPP URI in one example. 96 o Addressed Michael's issue with how timestamp are described. 98 o Renamed "valid_notif_method" to "valid_notify_method". 100 o Added text about truncation of a textual part when it is stored in 101 a variable using extract_text. 103 o Changed tagged :method argument to positional argument. 105 o Added text about notification throttling, identifying notification 106 source and restricting values of the :from parameter. 108 o Added a requirement on documents describing notification methods 109 to list which URI parameters must be ignored. 111 Changes since draft-ietf-sieve-notify-04 113 o Made notification method required. 115 o Defined "mailto" as a mandatory-to-implement method. 117 o Added normative reference to mailto. 119 o Clarified that :importance may be treated as a transport 120 indicator. 122 o Clarified that :importance value can be included in the default 123 :message, if one is not specified. 125 o Made the default :message implementation specific. 127 o Renamed the capability name from "notify" to "enotify" 129 o Updated IANA registration. 131 o Moved text about ManageSieve capability to the ManageSieve 132 document itself. 134 o Removed reference to IANA registry for options. 136 o Some miscellaneous text cleanup and clarification. 138 Changes since draft-ietf-sieve-notify-03 140 o Added a warning that "notify" must not be used as a crappy form of 141 "redirect". 143 o Added a warning about using "notify" to forward confidential 144 information in order to bypass organization's policy. 146 o Fixed syntax of the :options argument - it is a string list, each 147 string containing "=" 149 o Renamed :priority to :importance 151 o Cleaned up section about requirements on methods. 153 Changes since draft-ietf-sieve-notify-02 155 o Added :from tagged argument. 157 o Added Extract_text action, which allows to extract content of the 158 first text/* part. 160 o Added back the ":options" parameter to the notify action. 162 o Added new section talking about requirements on notification 163 method specs. 165 o Added more examples. 167 Changes since draft-ietf-sieve-notify-00 169 o Updated references, etc. 171 o Added IANA considerations section. 173 o Removed denotify action. 175 o Updated examples to use the variables extension. 177 o Replaced notification method with URI. 179 o Removed text suggesting that this extension can be used to track 180 all Sieve actions taken. 182 o Changed priority to be a string. 184 o Added text about URI verification. 186 o Clarified that a notification method is allowed to perform 187 adaptation of notification context (e.g. truncation, charset 188 conversion, etc.). These adaptations must be documented in a 189 document describing the notification method. 191 o Clarified that notify is compatible with all existing actions. 193 o Removed the :id parameter to the notify action. 195 o Added valid_notif_method test that allows to test if an 196 notification method (URI) is supported. 198 o Added a new capability response to ManageSieve that allows to 199 report supported notification types. 201 Table of Contents 203 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 204 1.1. Conventions used in this document . . . . . . . . . . . . . 7 206 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 7 208 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 7 209 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 7 210 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 7 211 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 8 212 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 8 213 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 9 214 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 9 215 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 216 3.8. Requirements on notification methods specifications . . . . 12 218 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13 220 5. Test notify_method_capability . . . . . . . . . . . . . . . 14 222 6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 15 224 7. Interactions with Other Sieve Actions . . . . . . . . . . . 16 226 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 228 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 229 9.1. Registration of Sieve extension . . . . . . . . . . . . . . 17 230 9.2. New registry for Sieve notification mechanisms . . . . . . . 18 232 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 234 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 235 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 18 236 11.2. Informative References . . . . . . . . . . . . . . . . . . . 19 237 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 238 Intellectual Property and Copyright Statements . . . . . . . 21 240 1. Introduction 242 This is an extension to the Sieve language defined by [Sieve] for 243 providing instant notifications. It defines the new action "notify". 245 This document does not specify the notification methods. Examples of 246 possible notification methods are email and XMPP. To allow a 247 mechanism for portability of scripts that use notifications, 248 implementation of the [MailTo] method is mandatory. Other available 249 methods shall depend upon the implementation and configuration of the 250 system. 252 1.1. Conventions used in this document 254 Conventions for notations are as in [Sieve] section 1.1, including 255 the use of [ABNF]. 257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 259 document are to be interpreted as described in [Kwds]. 261 2. Capability Identifier 263 The capability string associated with the extension defined in this 264 document is "enotify". 266 3. Notify Action 268 3.1. Notify Action Syntax and Semantics 270 Usage: notify [":from" string] 271 [":importance" <"1" / "2" / "3">] 272 [":options" string-list] 273 [":message" string] 274 276 The Notify action specifies that a notification should be sent to a 277 user. The format of the notification is implementation-defined and 278 is also affected by the notification method used (see Section 3.2). 279 However, all content specified in the :message parameter SHOULD be 280 included. 282 3.2. Notify parameter "method" 284 The method positional parameter identifies the notification method 285 that will be used; it is a URI [URI]. For example, the notification 286 method can be an SMS URI [SMS-URI] containing a phone number, or an 287 XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]. 289 The supported URI values will be site-specific, but support for the 290 [MailTo] method is REQUIRED in order to insure interoperability. If 291 a URI schema is specified that the implementation does not support, 292 the notification MUST cause an error condition. Sieve scripts can 293 check the supported methods using the "valid_notify_method" test to 294 be sure that they only use supported ones, to avoid such error 295 conditions. 297 If the method parameter contains a supported URI schema, then the URI 298 MUST be checked for syntactic validity. An invalid URI syntax or an 299 unsupported URI extension MUST cause an error. An implementation MAY 300 enforce other semantic restrictions on URIs -- for example to 301 restrict phone numbers in SMS URI to a particular geographical region 302 -- and will treat violations of such semantic restrictions as errors. 304 3.3. Notify tag ":from" 306 A ":from" parameter may be used to specify an author of the 307 notification. The syntax of this parameter's value is method- 308 specific. Implementations SHOULD check the syntax according to the 309 notification method specification and generate an error when a 310 syntactically invalid ":from" parameter is specified. 312 In order to minimize/prevent forgery of the author value, 313 implementations SHOULD impose restrictions on what values can 314 specified in a ":from" parameter. For example, an implementation may 315 restrict this value to be a member of a list of known author 316 addresses or to belong to a particular domain. It is suggested that 317 values which don't satisfy such restrictions simply be ignored rather 318 than causing the notify action to fail. 320 3.4. Notify tag ":importance" 322 The :importance tag specifies the importance of the delivery of the 323 notification. The :importance tag is followed by a numeric value 324 represented as a string: "1" (high importance), "2" (normal 325 importance), and "3" (low importance). If no importance is given, 326 the default value "2" SHOULD be assumed. A notification method can 327 treat the importance value as a transport indicator. For example, it 328 might deliver notifications of high importance quicker than 329 notifications of normal or low importance. Some notification methods 330 allow users to specify their state of activity (for example "busy" or 331 "away from keyboard"). If the notification method provides this 332 information it SHOULD be used to selectively send notifications. If, 333 for example, the user marks herself as "busy", a notification method 334 can require that a notification with importance of "3" is not to be 335 sent, however the user should be notified of a notification with 336 higher importance. 338 If the notification method allows users to filter messages based upon 339 certain parameters in the message, users SHOULD be able to filter 340 based upon importance. If the notification method does not support 341 importance, then this parameter MUST be ignored. An implementation 342 MAY include the importance value in the default message Section 3.6, 343 if one is not provided. 345 3.5. Notify tag ":options" 347 The :options tag is used to send additional parameters to the 348 notification method. Interpretation of the parameters is method- 349 specific. This document doesn't specify any such additional 350 parameter. 352 Each string in the options string list has the following syntax: 353 "=" 355 3.6. Notify tag ":message" 357 The :message tag specifies the message data to be included in the 358 notification. The entirety of the string SHOULD be sent but 359 implementations MAY shorten the message for technical or aesthetic 360 reasons. If the message parameter is absent, a default 361 implementation-specific message is used. Unless specified otherwise 362 by a particular notification mechanism, an implementation default 363 containing at least the value of the "From" header field and the 364 value of the "Subject" header field is RECOMMENDED. 366 In order to construct more complex messages the notify extension can 367 be used together with the Sieve variables extension [Variables], as 368 shown in the examples below. 370 3.7. Examples 371 Example 1: 372 require ["enotify", "fileinto", "variables"]; 374 if header :contains "from" "boss@example.org" { 375 notify :importance "1" 376 :message "This is probably very important" 377 "mailto:alm@example.com"; 378 # Don't send any further notifications 379 stop; 380 } 382 if header :contains "to" "sievemailinglist@example.org" { 383 # :matches is used to get the value of the Subject header 384 if header :matches "Subject" "*" { 385 set "subject" "${1}"; 386 } 388 # :matches is used to get the value of the From header 389 if header :matches "From" "*" { 390 set "from" "${1}"; 391 } 393 notify :importance "3" 394 :message "[SIEVE] ${from}: ${subject}" 395 "mailto:alm@example.com"; 396 fileinto "INBOX.sieve"; 397 } 399 Example 2: 400 require ["enotify", "fileinto", "variables", "envelope"]; 402 if header :matches "from" "*@*.example.org" { 403 # :matches is used to get the MAIL FROM address 404 if envelope :all :matches "from" "*" { 405 set "env_from" " [really: ${1}]"; 406 } 408 # :matches is used to get the value of the Subject header 409 if header :matches "Subject" "*" { 410 set "subject" "${1}"; 411 } 413 # :matches is used to get the address from the From header 414 if address :matches :all "from" "*" { 415 set "from_addr" "${1}"; 416 } 418 notify :message "${from_addr}${env_from}: ${subject}" 419 "mailto:alm@example.com"; 420 } 422 Example 3: 423 require ["enotify", "variables"]; 425 set "notif_method" 426 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; 428 if header :contains "subject" "Your dog" { 429 set "notif_method" "sms:+14085551212"; 430 } 432 if header :contains "to" "sievemailinglist@example.org" { 433 set "notif_method" ""; 434 } 436 if not string :is "${notif_method}" "" { 437 notify "${notif_method}"; 438 } 440 if header :contains "from" "boss@example.org" { 441 # :matches is used to get the value of the Subject header 442 if header :matches "Subject" "*" { 443 set "subject" "${1}"; 444 } 446 # don't need high importance notification for 447 # a 'for your information' 448 if not header :contains "subject" "FYI:" { 449 notify :importance "1" :message "BOSS: ${subject}" 450 "sms:+14085551212"; 451 } 452 } 454 3.8. Requirements on notification methods specifications 456 This section describes requirements for documents that define 457 specific Sieve notification methods. 459 A notification method MAY allow modification of the final 460 notification text -- for example, truncating it if it exceeds a 461 length limit, or modifying characters that can not be represented in 462 the target character set. Characters in the notification text which 463 can't be represented by the notification method SHOULD be replaced 464 with a symbol indicating an unknown character. Allowed modifications 465 MUST be documented in the document describing the notification 466 method. 468 A notification method MAY ignore parameters specified in the Notify 469 action. 471 A notification method MAY recommend the default message value to be 472 used if the :message argument is not specified. 474 Notifications SHOULD include timestamps, if the notification method 475 allows for their transmission outside of the textual message. 476 Implementation methods which can only transmit timestamps in the 477 textual message MAY include them in the textual message. 479 A notification SHOULD include means to identify/track its origin, in 480 order to allow a recipient to stop notifications or find out how to 481 contact the sender. This requirement is to help tracking a 482 misconfigured or abusive origin of notifications. 484 Methods SHOULD NOT include any other extraneous information not 485 specified in parameters to the notify action. 487 Methods MUST specify which URI parameters (if any) must be ignored, 488 which ones must be used in the resulting notification and which ones 489 must cause an error. 491 Methods MUST specify what values are returned by the 492 notify_method_capability test Section 5. 494 If there are errors sending the notification, the Sieve interpreter 495 SHOULD ignore the notification and not retry indefinitely. The Sieve 496 interpreter MAY throttle notifications; if it does, a request to send 497 a notification can be silently ignored. Documents describing 498 notification methods SHOULD describe how retries, throttling, 499 duplicate suppression (if any), etc. are to be handled by 500 implementations. 502 4. Test valid_notify_method 504 Usage: valid_notify_method 506 The "valid_notify_method" test is true if the notification methods 507 listed in the notification-uris argument are supported and they are 508 syntactically (including URI parameters) and semantically (including 509 implementation-specific semantic restrictions) valid. This test MUST 510 perform exactly the same validation as would be performed on the 511 "method" parameter to the "notify" action. 513 The test is true only if ALL of the listed notification methods are 514 supported and valid. 516 Example 4 (partial): 517 if not valid_notify_method ["mailto:", 518 "http://gw.example.net/notify?test"] { 519 stop; 520 } 522 5. Test notify_method_capability 524 Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE] 525 526 527 529 The "notify_method_capability" test retrieves the notification 530 capability specified by the notification-capability string that is 531 specific to the notification-uri and matches it to the values 532 specified in the key-list. The test succeeds if a match occurs. The 533 type of match defaults to ":is" and the default comparator is 534 "i;ascii-casemap". 536 The notification-capability is case insensitive. 538 The notify_method_capability test MUST fail unconditionally if the 539 specified notification-uri is syntactically invalid (as determined by 540 the valid_notify_method test Section 4) or specifies an unsupported 541 notification method. However this MUST NOT cause an error. 543 The notify_method_capability test MUST fail unconditionally if the 544 specified notification-capability item does not exist. A script MUST 545 NOT fail with an error if the item does not exist. This allows 546 scripts to be written that handle nonexistent items gracefully. 548 This document defines a single notification-capability value 549 "online", which is described below. Additional notification- 550 capability values may be defined by a Standard Track or Experimental 551 RFC. 553 For the "online" notification-capability the notify_method_capability 554 test can match one of the following key-list values: 556 o "yes" - the entity identified by the notification-uri can receive 557 a notify notification immediately. Note that even after this 558 value is returned, there is no guaranty that the entity would 559 actually be able to receive any notification immediately or even 560 receive it at all. Transport errors, recipient policy, etc. can 561 prevent that. 563 o "no" - the entity identified by the notification-uri is not 564 currently available to receive an immediate notification. 566 o "maybe" - Sieve interpreter can't determine if the the entity 567 identified by the notification-uri is online or not. 569 The "relational" extension [Relational] adds a match type called 570 ":count". The count of an notify_method_capability test is 0 if the 571 returned information is the empty string, or 1 otherwise. 573 Example 5: 574 require ["enotify"]; 576 if notify_method_capability 577 "xmpp:tim@example.com?message;subject=SIEVE" 578 "Online" 579 "yes" { 580 notify :importance "1" :message "You got mail" 581 "xmpp:tim@example.com?message;subject=SIEVE"; 582 } else { 583 notify :message "You got mail" "sms:+14085551212"; 584 } 586 6. Modifier encodeurl to the 'set' action 588 Usage: ":encodeurl" 590 When the Sieve script specifies both "variables" [Variables] and 591 "enotify" capabilities in the "require", a new "set" action modifier 592 (see [Variables]) ":encodeurl" becomes available to Sieve scripts. 593 This modifier performs percent-encoding of any octet in the string 594 which doesn't belong to the "unreserved" set (see [URI]). The 595 percent-encoding procedure is described in [URI]. 597 The ":encodeurl" modifier has precedence 15. 599 Example 6: 600 require ["enotify", "variables"]; 602 set :encodeurl "body_param" "Safe body&evil=evilbody"; 604 notify "mailto:tim@example.com?body=${body_param}"; 606 7. Interactions with Other Sieve Actions 608 The notify action is compatible with all other actions, and does not 609 affect the operation of other actions. In particular, the notify 610 action MUST NOT cancel the implicit keep. 612 Multiple executed notify actions are allowed. Specific notification 613 methods MAY allow multiple notifications from the same script to be 614 collapsed into one. 616 8. Security Considerations 618 Security considerations are discussed in [Sieve]. Additionally, 619 implementations must be careful to follow the security considerations 620 of the specific notification methods. 622 The notify action is potentially very dangerous. The path the 623 notification takes through the network may not be secure. An error 624 in the options string may cause the message to be transmitted to 625 someone it was not intended for, or may expose information to 626 eavesdroppers. 628 Just because a notification is received doesn't mean that it was sent 629 by the Sieve implementation. It might be possible to forge 630 notifications with some notification methods. 632 An organization may have a policy about the forwarding of classified 633 information to unclassified networks. Unless the policy is also 634 enforced in the module responsible for generating (or sending) of 635 notifications, users can use the extension defined in this document 636 to extract classified information and bypass the policy. 638 Notifications can result in loops and bounces. Also, allowing a 639 single script to notify multiple destinations can be used as a means 640 of amplifying the number of messages in an attack. Moreover, if loop 641 detection is not properly implemented it may be possible to set up 642 exponentially growing notification loops. Accordingly, Sieve 643 notification methods: 645 1. MUST provide mechanisms for avoiding notification loops. 647 2. MUST provide the means for administrators to limit the ability of 648 users to abuse notify. In particular, it MUST be possible to 649 limit the number of notify actions a script can perform. 650 Additionally, if no use cases exist for using notify with 651 multiple destinations, this limit SHOULD be set to 1. Additional 652 limits, such as the ability to restrict notify to local users MAY 653 also be implemented. 655 3. MUST provide facilities to log use of notify in order to 656 facilitate tracking down abuse. 658 4. MAY use script analysis to determine whether or not a given 659 script can be executed safely. While the Sieve language is 660 sufficiently complex that full analysis of all possible scripts 661 is computationally infeasible, the majority of real-world scripts 662 are amenable to analysis. For example, an implementation might 663 allow scripts that it has determined are safe to run unhindered, 664 block scripts that are potentially problematic, and subject 665 unclassifiable scripts to additional auditing and logging. 667 Allowing notify action at all may not be appropriate in situations 668 where Sieve scripts are associated with email accounts which are 669 freely-available and/or not trackable to a human who can be held 670 accountable for creating message bombs or other abuse. 672 Implementations that construct URIs internally from various notify 673 parameters MUST make sure that all components of such URIs are 674 properly percent-encoded (see [URI]). In particular this applies to 675 values of the :from and the :message tagged arguments and may apply 676 to the :options values. 678 9. IANA Considerations 680 9.1. Registration of Sieve extension 682 The following template specifies the IANA registration of the notify 683 Sieve extension specified in this document: 685 To: iana@iana.org 686 Subject: Registration of new Sieve extension 687 Capability name: enotify 688 Description: adds the 'notify' action for notifying user about the 689 received message. It also provides two new test: valid_notify_method 690 checks notification URIs for validity; notify_method_capability can 691 check recipients capabilities. 692 RFC number: this RFC 693 Contact address: 694 The Sieve discussion list 696 This information should be added to the list of sieve extensions 697 given on http://www.iana.org/assignments/sieve-extensions. 699 9.2. New registry for Sieve notification mechanisms 701 This defines the template for a new registry for Sieve notification 702 mechanisms, to be created as 703 http://www.iana.org/assignments/sieve-notification. There are no 704 initial entries for this registry. 706 To: iana@iana.org 707 Subject: Registration of new Sieve notification mechanism 708 Mechanism name: [the name of the mechanism] 709 Mechanism URI: [the RFC number of the document that defines the URI 710 used by this mechanism] 711 Mechanism-specific tags: [the names of any Sieve notify tags that are 712 specific to this mechanism, or "none"] 713 Standards Track/IESG-approved experimental RFC number: [the RFC 714 number of the document that defines this notification mechanism] 715 Person and email address to contact for further information: [the 716 name and email address of the technical contact for information about 717 this mechanism] 719 10. Acknowledgements 721 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 722 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 723 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen 724 and Peter Saint-Andre for help with this document. 726 11. References 728 11.1. Normative References 730 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 731 Specifications: ABNF", RFC 4234, October 2005. 733 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", RFC 2119, March 1997. 736 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 737 mailto", work in progress, draft-ietf-sieve-notify-mailto, 738 October 2006. 740 [Relational] 741 Segmuller, W. and B. Leiba, "Sieve Extension: Relational 742 Tests", work in progress, draft-ietf-sieve-3431bis, 743 December 2005. 745 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 746 Language", work in progress, draft-ietf-sieve-3028bis, 747 August 2006. 749 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 750 Resource Identifier (URI): Generic Syntax", STD 66, 751 RFC 3986, January 2005. 753 [Variables] 754 Homme, K., "Sieve Extension: Variables", work in 755 progress, draft-ietf-sieve-variables, December 2005. 757 11.2. Informative References 759 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 760 Message Service", work in progress, draft-wilde-sms-uri, 761 August 2005. 763 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 764 Protocol (XMPP): Core", RFC 3920, October 2004. 766 [XMPP-URI] 767 Saint-Andre, P., "Internationalized Resource Identifiers 768 (IRIs) and Uniform Resource Identifiers (URIs) for the 769 Extensible Messaging and Presence Protocol (XMPP)", work 770 in progress, draft-saintandre-xmpp-iri, September 2005. 772 Authors' Addresses 774 Alexey Melnikov (editor) 775 Isode Limited 776 5 Castle Business Village 777 36 Station Road 778 Hampton, Middlesex TW12 2BX 779 UK 781 Email: Alexey.Melnikov@isode.com 782 Barry Leiba (editor) 783 IBM T.J. Watson Research Center 784 19 Skyline Drive 785 Hawthorne, NY 10532 786 US 788 Phone: +1 914 784 7941 789 Email: leiba@watson.ibm.com 791 Wolfgang Segmuller 792 IBM T.J. Watson Research Center 793 19 Skyline Drive 794 Hawthorne, NY 10532 795 US 797 Phone: +1 914 784 7408 798 Email: werewolf@us.ibm.com 800 Tim Martin 801 BeThereBeSquare Inc. 802 672 Haight st. 803 San Francisco, CA 94117 804 US 806 Phone: +1 510 260-4175 807 Email: timmartin@alumni.cmu.edu 809 Full Copyright Statement 811 Copyright (C) The IETF Trust (2007). 813 This document is subject to the rights, licenses and restrictions 814 contained in BCP 78, and except as set forth therein, the authors 815 retain all their rights. 817 This document and the information contained herein are provided on an 818 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 819 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 820 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 821 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 822 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 823 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 825 Intellectual Property 827 The IETF takes no position regarding the validity or scope of any 828 Intellectual Property Rights or other rights that might be claimed to 829 pertain to the implementation or use of the technology described in 830 this document or the extent to which any license under such rights 831 might or might not be available; nor does it represent that it has 832 made any independent effort to identify any such rights. Information 833 on the procedures with respect to rights in RFC documents can be 834 found in BCP 78 and BCP 79. 836 Copies of IPR disclosures made to the IETF Secretariat and any 837 assurances of licenses to be made available, or the result of an 838 attempt made to obtain a general license or permission for the use of 839 such proprietary rights by implementers or users of this 840 specification can be obtained from the IETF on-line IPR repository at 841 http://www.ietf.org/ipr. 843 The IETF invites any interested party to bring to its attention any 844 copyrights, patents or patent applications, or other proprietary 845 rights that may cover technology that may be required to implement 846 this standard. Please address the information to the IETF at 847 ietf-ipr@ietf.org. 849 Acknowledgment 851 Funding for the RFC Editor function is provided by the IETF 852 Administrative Support Activity (IASA).