idnits 2.17.1 draft-ietf-sieve-notify-09.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 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. 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 (October 5, 2007) is 6048 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 514, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 514, 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: April 7, 2008 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 October 5, 2007 11 SIEVE Email Filtering: Notifications 12 draft-ietf-sieve-notify-09 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 April 7, 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-08 58 o Added missing IANA registry for notification methods. 60 Changes since draft-ietf-sieve-notify-07 62 o Added a new "set" modifier for URL percent-encoding. 64 o Clarified that notification methods must address notification 65 loops. 67 o Added an implementation consideration for implementations that use 68 URIs internally. 70 Changes since draft-ietf-sieve-notify-06 72 o Remove extract_text. The WG consensus was to move it to another 73 document, such as Sieve MIME loops. 75 o Deleted markers for open issues from the document. 77 o Clarified that a notification mechanism can treat some URI 78 parameters as an error. 80 o Added notify_method_capability test and example. 82 o Minor corrections to the IANA registration as a result of other 83 changes. 85 Changes since draft-ietf-sieve-notify-05 87 o Fixed XMPP URI in one example. 89 o Addressed Michael's issue with how timestamp are described. 91 o Renamed "valid_notif_method" to "valid_notify_method". 93 o Added text about truncation of a textual part when it is stored in 94 a variable using extract_text. 96 o Changed tagged :method argument to positional argument. 98 o Added text about notification throttling, identifying notification 99 source and restricting values of the :from parameter. 101 o Added a requirement on documents describing notification methods 102 to list which URI parameters must be ignored. 104 Changes since draft-ietf-sieve-notify-04 106 o Made notification method required. 108 o Defined "mailto" as a mandatory-to-implement method. 110 o Added normative reference to mailto. 112 o Clarified that :importance may be treated as a transport 113 indicator. 115 o Clarified that :importance value can be included in the default 116 :message, if one is not specified. 118 o Made the default :message implementation specific. 120 o Renamed the capability name from "notify" to "enotify" 122 o Updated IANA registration. 124 o Moved text about ManageSieve capability to the ManageSieve 125 document itself. 127 o Removed reference to IANA registry for options. 129 o Some miscellaneous text cleanup and clarification. 131 Changes since draft-ietf-sieve-notify-03 133 o Added a warning that "notify" must not be used as a crappy form of 134 "redirect". 136 o Added a warning about using "notify" to forward confidential 137 information in order to bypass organization's policy. 139 o Fixed syntax of the :options argument - it is a string list, each 140 string containing "=" 142 o Renamed :priority to :importance 143 o Cleaned up section about requirements on methods. 145 Changes since draft-ietf-sieve-notify-02 147 o Added :from tagged argument. 149 o Added Extract_text action, which allows to extract content of the 150 first text/* part. 152 o Added back the ":options" parameter to the notify action. 154 o Added new section talking about requirements on notification 155 method specs. 157 o Added more examples. 159 Changes since draft-ietf-sieve-notify-00 161 o Updated references, etc. 163 o Added IANA considerations section. 165 o Removed denotify action. 167 o Updated examples to use the variables extension. 169 o Replaced notification method with URI. 171 o Removed text suggesting that this extension can be used to track 172 all Sieve actions taken. 174 o Changed priority to be a string. 176 o Added text about URI verification. 178 o Clarified that a notification method is allowed to perform 179 adaptation of notification context (e.g. truncation, charset 180 conversion, etc.). These adaptations must be documented in a 181 document describing the notification method. 183 o Clarified that notify is compatible with all existing actions. 185 o Removed the :id parameter to the notify action. 187 o Added valid_notif_method test that allows to test if an 188 notification method (URI) is supported. 190 o Added a new capability response to ManageSieve that allows to 191 report supported notification types. 193 Table of Contents 195 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 196 1.1. Conventions used in this document . . . . . . . . . . . . . 6 198 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 6 200 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 6 201 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 6 202 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 6 203 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 7 204 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 7 205 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 8 206 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 8 207 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 208 3.8. Requirements on notification methods specifications . . . . 11 210 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 12 212 5. Test notify_method_capability . . . . . . . . . . . . . . . 13 214 6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 14 216 7. Interactions with Other Sieve Actions . . . . . . . . . . . 15 218 8. Security Considerations . . . . . . . . . . . . . . . . . . 15 220 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 221 9.1. Registration of Sieve extension . . . . . . . . . . . . . . 16 222 9.2. New registry for Sieve notification mechanisms . . . . . . . 16 224 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 226 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 227 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 17 228 11.2. Informative References . . . . . . . . . . . . . . . . . . . 17 230 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 231 Intellectual Property and Copyright Statements . . . . . . . 19 233 1. Introduction 235 This is an extension to the Sieve language defined by [Sieve] for 236 providing instant notifications. It defines the new action "notify". 238 This document does not specify the notification methods. Examples of 239 possible notification methods are email and XMPP. To allow a 240 mechanism for portability of scripts that use notifications, 241 implementation of the [MailTo] method is mandatory. Other available 242 methods shall depend upon the implementation and configuration of the 243 system. 245 1.1. Conventions used in this document 247 Conventions for notations are as in [Sieve] section 1.1, including 248 the use of [ABNF]. 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in [Kwds]. 254 2. Capability Identifier 256 The capability string associated with the extension defined in this 257 document is "enotify". 259 3. Notify Action 261 3.1. Notify Action Syntax and Semantics 263 Usage: notify [":from" string] 264 [":importance" <"1" / "2" / "3">] 265 [":options" string-list] 266 [":message" string] 267 269 The Notify action specifies that a notification should be sent to a 270 user. The format of the notification is implementation-defined and 271 is also affected by the notification method used (see Section 3.2). 272 However, all content specified in the :message parameter SHOULD be 273 included. 275 3.2. Notify parameter "method" 277 The method positional parameter identifies the notification method 278 that will be used; it is a URI [URI]. For example, the notification 279 method can be an SMS URI [SMS-URI] containing a phone number, or an 280 XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]. 282 The supported URI values will be site-specific, but support for the 283 [MailTo] method is REQUIRED in order to insure interoperability. If 284 a URI schema is specified that the implementation does not support, 285 the notification MUST cause an error condition. Sieve scripts can 286 check the supported methods using the "valid_notify_method" test to 287 be sure that they only use supported ones, to avoid such error 288 conditions. 290 If the method parameter contains a supported URI schema, then the URI 291 MUST be checked for syntactic validity. An invalid URI syntax or an 292 unsupported URI extension MUST cause an error. An implementation MAY 293 enforce other semantic restrictions on URIs -- for example an SMS URI 294 can only contain phone numbers in a particular geographical region -- 295 and will treat violations of such semantic restrictions as errors. 297 3.3. Notify tag ":from" 299 A ":from" parameter may be used to specify an author of the 300 notification. The syntax of this parameter's value is method- 301 specific. Implementations SHOULD check the syntax according to the 302 notification method specification and generate an error when a 303 syntactically invalid ":from" parameter is specified. In order to 304 minimize/prevent forgery of the author value, implementations SHOULD 305 impose restrictions on what values can specified in a ":from" 306 parameter; it is suggested that values which fail such a validity 307 check simply be ignored rather than causing the notify action to 308 fail. 310 3.4. Notify tag ":importance" 312 The :importance tag specifies the importance of the delivery of the 313 notification. The :importance tag is followed by a numeric value 314 represented as a string: "1" (high importance), "2" (normal 315 importance), and "3" (low importance). If no importance is given, 316 the default value "2" SHOULD be assumed. A notification method can 317 treat the importance value as a transport indicator. For example, it 318 might deliver notifications of high importance quicker than 319 notifications of normal or low importance. Some notification methods 320 allow users to specify their state of activity (for example "busy" or 321 "away from keyboard"). If the notification method provides this 322 information it SHOULD be used to selectively send notifications. If, 323 for example, the user marks herself as "busy", a notification method 324 can require that a notification with importance of "3" is not to be 325 sent, however the user should be notified of a notification with 326 higher importance. 328 If the notification method allows users to filter messages based upon 329 certain parameters in the message, users SHOULD be able to filter 330 based upon importance. If the notification method does not support 331 importance, then this parameter MUST be ignored. An implementation 332 MAY include the importance value in the default message Section 3.6, 333 if one is not provided. 335 3.5. Notify tag ":options" 337 The :options tag is used to send additional parameters to the 338 notification method. Interpretation of the parameters is method- 339 specific. This document doesn't specify any such additional 340 parameter. 342 Each string in the options string list has the following syntax: 343 "=" 345 3.6. Notify tag ":message" 347 The :message tag specifies the message data to be included in the 348 notification. The entirety of the string SHOULD be sent but 349 implementations MAY shorten the message for technical or aesthetic 350 reasons. If the message parameter is absent, a default 351 implementation-specific message is used. Unless specified otherwise 352 by a particular notification mechanism, an implementation default 353 containing at least the value of the "From" header field and the 354 value of the "Subject" header field is RECOMMENDED. 356 In order to construct more complex messages the notify extension can 357 be used together with the Sieve variables extension [Variables], as 358 shown in the examples below. 360 3.7. Examples 361 Example 1: 362 require ["enotify", "fileinto", "variables"]; 364 if header :contains "from" "boss@example.org" { 365 notify :importance "1" 366 :message "This is probably very important" 367 "mailto:alm@example.com"; 368 # Don't send any further notifications 369 stop; 370 } 372 if header :contains "to" "sievemailinglist@example.org" { 373 # :matches is used to get the value of the Subject header 374 if header :matches "Subject" "*" { 375 set "subject" "${1}"; 376 } 378 # :matches is used to get the value of the From header 379 if header :matches "From" "*" { 380 set "from" "${1}"; 381 } 383 notify :importance "3" 384 :message "[SIEVE] ${from}: ${subject}" 385 "mailto:alm@example.com"; 386 fileinto "INBOX.sieve"; 387 } 389 Example 2: 390 require ["enotify", "fileinto", "variables", "envelope"]; 392 if header :matches "from" "*@*.example.org" { 393 # :matches is used to get the MAIL FROM address 394 if envelope :all :matches "from" "*" { 395 set "env_from" " [really: ${1}]"; 396 } 398 # :matches is used to get the value of the Subject header 399 if header :matches "Subject" "*" { 400 set "subject" "${1}"; 401 } 403 # :matches is used to get the address from the From header 404 if address :matches :all "from" "*" { 405 set "from_addr" "${1}"; 406 } 408 notify :message "${from_addr}${env_from}: ${subject}" 409 "mailto:alm@example.com"; 410 } 412 Example 3: 413 require ["enotify", "variables"]; 415 set "notif_method" 416 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; 418 if header :contains "subject" "Your dog" { 419 set "notif_method" "sms:+14085551212"; 420 } 422 if header :contains "to" "sievemailinglist@example.org" { 423 set "notif_method" ""; 424 } 426 if not string :is "${notif_method}" "" { 427 notify "${notif_method}"; 428 } 430 if header :contains "from" "boss@example.org" { 431 # :matches is used to get the value of the Subject header 432 if header :matches "Subject" "*" { 433 set "subject" "${1}"; 434 } 436 # don't need high importance notification for 437 # a 'for your information' 438 if not header :contains "subject" "FYI:" { 439 notify :importance "1" :message "BOSS: ${subject}" 440 "sms:+14085551212"; 441 } 442 } 444 3.8. Requirements on notification methods specifications 446 This section describes requirements for documents that define 447 specific Sieve notification methods. 449 A notification method MAY allow modification of the final 450 notification text -- for example, truncating it if it exceeds a 451 length limit, or modifying characters that can not be represented in 452 the target character set. Characters in the notification text which 453 can't be represented by the notification method SHOULD be replaced 454 with a symbol indicating an unknown character. Allowed modifications 455 MUST be documented in the document describing the notification 456 method. 458 A notification method MAY ignore parameters specified in the Notify 459 action. 461 A notification method MAY recommend the default message value to be 462 used if the :message argument is not specified. 464 Notifications SHOULD include timestamps, if the notification method 465 allows for their transmission outside of the textual message. 466 Implementation methods which can only transmit timestamps in the 467 textual message MAY include them in the textual message. 469 A notification SHOULD include means to identify/track its origin, in 470 order to allow a recipient to stop notifications or find out how to 471 contact the sender. This requirement is to help tracking a 472 misconfigured or abusive origin of notifications. 474 Methods SHOULD NOT include any other extraneous information not 475 specified in parameters to the notify action. 477 Methods MUST specify which URI parameters (if any) must be ignored, 478 which ones must be used in the resulting notification and which ones 479 must cause an error. 481 Methods MUST specify what values are returned by the 482 notify_method_capability test Section 5. 484 If there are errors sending the notification, the Sieve interpreter 485 SHOULD ignore the notification and not retry indefinitely. The Sieve 486 interpreter MAY throttle notifications; if it does, a request to send 487 a notification can be silently ignored. Documents describing 488 notification methods SHOULD describe how retries, throttling, 489 duplicate suppression (if any), etc. are to be handled by 490 implementations. 492 4. Test valid_notify_method 494 Usage: valid_notify_method 496 The "valid_notify_method" test is true if the notification methods 497 listed in the notification-uris argument are supported and they are 498 syntactically (including URI parameters) and semantically (including 499 implementation-specific semantic restrictions) valid. This test MUST 500 perform exactly the same validation as would be performed on the 501 "method" parameter to the "notify" action. 503 The test is true only if ALL of the listed notification methods are 504 supported and valid. 506 Example 4 (partial): 507 if not valid_notify_method ["mailto:", 508 "http://gw.example.net/notify?test"] { 509 stop; 510 } 512 5. Test notify_method_capability 514 Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE] 515 516 517 519 The "notify_method_capability" test retrieves the notification 520 capability specified by the notification-capability string that is 521 specific to the notification-uri and matches it to the values 522 specified in the key-list. The test succeeds if a match occurs. The 523 type of match defaults to ":is" and the default comparator is 524 "i;ascii-casemap". 526 The notification-capability is case insensitive. 528 The notify_method_capability test MUST fail unconditionally if the 529 specified notification-uri is syntactically invalid (as determined by 530 the valid_notify_method test Section 4) or specifies an unsupported 531 notification method. However this MUST NOT cause an error. 533 The notify_method_capability test MUST fail unconditionally if the 534 specified notification-capability item does not exist. A script MUST 535 NOT fail with an error if the item does not exist. This allows 536 scripts to be written that handle nonexistent items gracefully. 538 This document defines a single notification-capability value 539 "online", which is described below. Additional notification- 540 capability values may be defined by a Standard Track or Experimental 541 RFC. 543 For the "online" notification-capability the notify_method_capability 544 test can match one of the following key-list values: 546 o "yes" - the entity identified by the notification-uri can receive 547 a notify notification immediately. Note that even after this 548 value is returned, there is no guaranty that the entity would 549 actually be able to receive any notification immediately or even 550 receive it at all. Transport errors, recipient policy, etc. can 551 prevent that. 553 o "no" - the entity identified by the notification-uri is not 554 currently available to receive an immediate notification. 556 o "maybe" - Sieve interpreter can't determine if the the entity 557 identified by the notification-uri is online or not. 559 The "relational" extension [Relational] adds a match type called 560 ":count". The count of an notify_method_capability test is 0 if the 561 returned information is the empty string, or 1 otherwise. 563 Example 5: 564 require ["enotify"]; 566 if notify_method_capability 567 "xmpp:tim@example.com?message;subject=SIEVE" 568 "Online" 569 "yes" { 570 notify :importance "1" :message "You got mail" 571 "xmpp:tim@example.com?message;subject=SIEVE"; 572 } else { 573 notify :message "You got mail" "sms:+14085551212"; 574 } 576 6. Modifier encodeurl to the 'set' action 578 Usage: ":encodeurl" 580 When the Sieve script specifies both "variables" [Variables] and 581 "enotify" capabilities in the "require", a new "set" action modifier 582 (see [Variables]) ":encodeurl" becomes available to Sieve scripts. 583 This modifier performs percent-encoding of any octet in the string 584 which doesn't belong to the "unreserved" set (see [URI]). The 585 percent-encoding procedure is described in [URI]. 587 The ":encodeurl" modifier has precedence 15. 589 Example 6: 590 require ["enotify", "variables"]; 592 set :encodeurl "body_param" "Safe body&evil=evilbody"; 594 notify "mailto:tim@example.com?body=${body_param}"; 596 7. Interactions with Other Sieve Actions 598 The notify action is compatible with all other actions, and does not 599 affect the operation of other actions. In particular, the notify 600 action MUST NOT cancel the implicit keep. 602 Multiple executed notify actions are allowed. Specific notification 603 methods MAY allow multiple notifications from the same script to be 604 collapsed into one. 606 8. Security Considerations 608 Security considerations are discussed in [Sieve]. Additionally, 609 implementations must be careful to follow the security considerations 610 of the specific notification methods. 612 The notify action is potentially very dangerous. The path the 613 notification takes through the network may not be secure. An error 614 in the options string may cause the message to be transmitted to 615 someone it was not intended for, or may expose information to 616 eavesdroppers. 618 Just because a notification is received doesn't mean that it was sent 619 by the Sieve implementation. It might be possible to forge 620 notifications with some notification methods. 622 An organization may have a policy about the forwarding of classified 623 information to unclassified networks. Unless the policy is also 624 enforced in the module responsible for generating (or sending) of 625 notifications, users can use the extension defined in this document 626 to extract classified information and bypass the policy. 628 Notifications can result in loops and bounces. In particular, a 629 notification to an email address will not contain necessary Received 630 header fields that might be otherwise used to prevent mail loops. 631 All notification methods MUST take care to provide mechanisms for 632 avoiding notification loops. 634 Implementations that construct URIs internally from various notify 635 parameters MUST make sure that all components of such URIs are 636 properly percent-encoded (see [URI]). In particular this applies to 637 values of the :from and the :message tagged arguments and may apply 638 to the :options values. 640 9. IANA Considerations 642 9.1. Registration of Sieve extension 644 The following template specifies the IANA registration of the notify 645 Sieve extension specified in this document: 647 To: iana@iana.org 648 Subject: Registration of new Sieve extension 649 Capability name: enotify 650 Description: adds the 'notify' action for notifying user about the 651 received message. It also provides two new test: valid_notify_method 652 checks notification URIs for validity; notify_method_capability can 653 check recipients capabilities. 654 RFC number: this RFC 655 Contact address: 656 The Sieve discussion list 658 This information should be added to the list of sieve extensions 659 given on http://www.iana.org/assignments/sieve-extensions. 661 9.2. New registry for Sieve notification mechanisms 663 This defines the template for a new registry for Sieve notification 664 mechanisms, to be created as 665 http://www.iana.org/assignments/sieve-notification. There are no 666 initial entries for this registry. 668 To: iana@iana.org 669 Subject: Registration of new Sieve notification mechanism 670 Mechanism name: [the name of the mechanism] 671 Mechanism URI: [the RFC number of the document that defines the URI 672 used by this mechanism] 673 Mechanism-specific tags: [the names of any Sieve notify tags that are 674 specific to this mechanism, or "none"] 675 Standards Track/IESG-approved experimental RFC number: [the RFC 676 number of the document that defines this notification mechanism] 677 Person and email address to contact for further information: [the 678 name and email address of the technical contact for information about 679 this mechanism] 681 10. Acknowledgements 683 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 684 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 685 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen 686 and Peter Saint-Andre for help with this document. 688 11. References 690 11.1. Normative References 692 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 693 Specifications: ABNF", RFC 4234, October 2005. 695 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", RFC 2119, March 1997. 698 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 699 mailto", work in progress, draft-ietf-sieve-notify-mailto, 700 October 2006. 702 [Relational] 703 Segmuller, W. and B. Leiba, "Sieve Extension: Relational 704 Tests", work in progress, draft-ietf-sieve-3431bis, 705 December 2005. 707 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 708 Language", work in progress, draft-ietf-sieve-3028bis, 709 August 2006. 711 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 712 Resource Identifier (URI): Generic Syntax", STD 66, 713 RFC 3986, January 2005. 715 [Variables] 716 Homme, K., "Sieve Extension: Variables", work in 717 progress, draft-ietf-sieve-variables, December 2005. 719 11.2. Informative References 721 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 722 Message Service", work in progress, draft-wilde-sms-uri, 723 August 2005. 725 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 726 Protocol (XMPP): Core", RFC 3920, October 2004. 728 [XMPP-URI] 729 Saint-Andre, P., "Internationalized Resource Identifiers 730 (IRIs) and Uniform Resource Identifiers (URIs) for the 731 Extensible Messaging and Presence Protocol (XMPP)", work 732 in progress, draft-saintandre-xmpp-iri, September 2005. 734 Authors' Addresses 736 Alexey Melnikov (editor) 737 Isode Limited 738 5 Castle Business Village 739 36 Station Road 740 Hampton, Middlesex TW12 2BX 741 UK 743 Email: Alexey.Melnikov@isode.com 745 Barry Leiba (editor) 746 IBM T.J. Watson Research Center 747 19 Skyline Drive 748 Hawthorne, NY 10532 749 US 751 Phone: +1 914 784 7941 752 Email: leiba@watson.ibm.com 754 Wolfgang Segmuller 755 IBM T.J. Watson Research Center 756 19 Skyline Drive 757 Hawthorne, NY 10532 758 US 760 Phone: +1 914 784 7408 761 Email: werewolf@us.ibm.com 763 Tim Martin 764 BeThereBeSquare Inc. 765 672 Haight st. 766 San Francisco, CA 94117 767 US 769 Phone: +1 510 260-4175 770 Email: timmartin@alumni.cmu.edu 772 Full Copyright Statement 774 Copyright (C) The IETF Trust (2007). 776 This document is subject to the rights, licenses and restrictions 777 contained in BCP 78, and except as set forth therein, the authors 778 retain all their rights. 780 This document and the information contained herein are provided on an 781 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 782 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 783 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 784 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 785 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 786 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Intellectual Property 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Acknowledgment 814 Funding for the RFC Editor function is provided by the IETF 815 Administrative Support Activity (IASA).