idnits 2.17.1 draft-ietf-sieve-imapflags-05.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 737 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6548 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: 'MATCH-TYPE' is mentioned on line 409, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 409, but not defined == Unused Reference: 'KEYWORDS' is defined on line 648, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- No information found for draft-ietf-sieve-variables-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VARIABLES' -- No information found for draft-ietf-sieve-3431bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RELATIONAL' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft: Sieve -- IMAP flag Extension A. Melnikov 3 Document: draft-ietf-sieve-imapflags-05.txt Isode Limited 4 Expires: November 2006 May 2006 6 SIEVE Email Filtering: IMAP flag Extension 8 Status of this memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Recent discussions have shown that it is desirable to set different 33 IMAP (RFC 3501) flags on message delivery. This can be done, for 34 example, by a Sieve interpreter that works as a part of a Mail 35 Delivery Agent. 37 This document describes an extension to the Sieve mail filtering 38 language for setting IMAP flags. The extension allows to set both 39 IMAP system flags and IMAP keywords. 41 0. Meta-information on this draft 43 This information is intended to facilitate discussion. It will be 44 removed when this document leaves the Internet-Draft stage. 46 0.1. Discussion 48 This draft defines an extension to the Sieve mail filtering 49 language (RFC 3028) being discussed on the MTA Filters 50 mailing list at . Subscription requests 51 can be sent to (send an email 52 message with the word "subscribe" in the body). More information on 53 the mailing list along with a WWW archive of back messages is 54 available at . 56 0.2. Changes from the version submitted to the Sieve mailing list 58 1. Added addflag and removeflag actions 60 2. Changed the semantics of setflag (setflag is not additive any 61 more) 63 3. Corrected section "Interaction with Other Sieve Actions". 64 Removed incorrect reference to the forward action as to an 65 action that prohibits setflag. 67 4. Added paragraph about the mutual order of "fileinto"/"keep" and 68 "setflag"/"addflag"/"removeflag" actions. 70 0.3. Changes from the revision 00 72 1. Corrected Capability Identifier section (Section 2) 74 2. Corrected "Interaction with Other Sieve Actions" section 75 (Section 4) 77 3. Examples were updated to be compatible with Sieve-07 draft 79 4. Added "mark" and "unmark" actions 81 0.4. Changes from the revision 01 83 1. Some language fixes based on Tony Hansen comments 85 2. Clarified that the extension allows to set both IMAP System 86 Flags and Keywords 88 0.5. Changes from the revision 02 90 1. BugFix: all backslashes must be escaped 92 2. Added extended example and more detailed description of 93 "addflag"/"removeflag" additivity. 95 3. Minor example bugfixes 97 0.6. Changes from the revision 03 99 1. Added second way to specify flags to be set (via optional tagged 100 arguments). [Tim Showalter] 102 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 104 3. Removed ABNF section completely, added syntax description to 105 action definition. [Tim Showalter] 107 4. Cleaned up the example. [Ken Murchison] 109 5. Added FM (Flag Manupulation) acronym. 111 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 113 0.7. Changes from the revision 04 115 1. "Interaction with Other Sieve Actions" was simplified based on 116 comments from Tim Showalter. Added sentence saying that 117 imapflags doesn't change an implicit keep. 119 2. Several editorial comments from Tim Showalter. 121 0.8. Changes from the revision 05 123 1. Updated copyright, author address, section numbers and references. 125 2. Added dependency on Sieve "variables" extension. 127 3. Several editorial comments from Matthew Elvey. 129 4. Removed "mark" and "unmark" actions. 131 5. Added "hasflag" test. 133 6. Dropped ":globalflags" 135 7. An invalid flag name doesn't cause a script execution failure 136 anymore, as imapflags now depends on variables and a variable 137 can have an arbitrary value. 139 0.9. Changes from the revision 06 (draft-ietf-sieve-imapflags-00.txt) 141 1. Updated boilerplate and references. 143 2. Fixed capability string in the extended example. 145 3. Improved implementation using macros (section 6). 147 0.10. Changes from draft-ietf-sieve-imapflags-00.txt 149 1. Added back the internal variable, made the variable parameter 150 to all actions optional. 152 2. Some editorial suggestions from Mark E. Mallett. 154 3. Updated boilerplate once again. 156 0.11. Changes from draft-ietf-sieve-imapflags-01.txt 158 1. Clarified that if "variables" is not available, then usage of 159 the explicit variable parameter causes a runtime error. 161 2. Clarified handling of spaces, in particular that leading/ 162 trailing spaces in a flag variable are to be ignored. 164 3. Clarified that the extension can't be used to set the \Recent 165 flag. 167 4. Made the variable list parameter to hasflag test optional, for 168 consistency with all actions. 170 5. Dropped the "Implementation Notes" section. 172 6. Fixed an error in section 5: when the :flags tagged argument is 173 not specified, the correct behavior is to use flags from the 174 internal variable. 176 7. Other minor editorial changes. 178 0.12. Changes from draft-ietf-sieve-imapflags-02.txt 180 1. Changed "Syntax:" label to "Usage:". 182 2. Updated the Introduction section to mention that hasflag also has 183 an optional parameter. 185 3. Clarified that a failure to store flags for a message is not 186 a runtime error. 188 4. Minor editorial nits from Philip. 190 5. Addressed ID nits. 192 0.13. Changes from draft-ietf-sieve-imapflags-03.txt 194 1. Minor editorial changes from Ken. 196 2. Added IANA Considerations section. 198 3. Clarified "hasflag" behaviour with :matches, :contains, etc. 200 4. Added optional comparator field to "hasflag" test, for 201 consistency with other extensions. 203 5. Clarified interaction of hasflag with the relational extension. 205 0.14. Changes from draft-ietf-sieve-imapflags-04.txt 207 1. Extended an example in section 4. 209 2. Fixed several typos. 211 3. Changed some examples to show that some parameters are optional 212 (Cyrus) 214 4. Addressed comments raised during IESG evaluation, in particular: 216 Clarified that space is used as delimiter between flag names. 218 Described capabilities provided by the extension as they are 219 visible to end users. 221 1. Introduction 223 This is an extension to the Sieve language defined by [SIEVE] for 224 setting [IMAP] flags. It adds a new tagged argument to "keep" and 225 "fileinto" that describes the list of flags that have to be set 226 when the message is delivered to the specified mailbox. It also 227 adds several actions to help manipulate list of flags and a test 228 to check if a flag belongs to a list. 230 From user's prospective this extension provides several 231 capabilities. First, it allows manipulation of sets of IMAP flags. 232 Second, it gives ability to associate a set of IMAP flags with 233 a message that is delivered to a mailstore using the keep/fileinto 234 actions. Third, it maintains an internal variable. The internal 235 variable contains the default flags that will be associated with 236 a message that is delivered using the keep, implicit keep or fileinto 237 actions, when the :flags tagged argument is not specified. 238 When the Sieve [VARIABLES] extension is also supported by the Sieve 239 engine, it enables support for multiple variables containing sets 240 of IMAP flags. 242 The capability string associated with extension defined in this 243 document is "imap4flags". All conformant implementations MUST 244 implement all Sieve actions (Setflag, Addflag, Removeflag), 245 the hasflag test and the :flags tagged argument described in this 246 document. 248 The "imap4flags" extension can be used with or without the 249 "variables" extension [VARIABLES]. When the "variables" extension 250 is enabled in a script using , the script can 251 use explicit variable names in setflag/addflag/removeflag actions 252 and hasflag test. See also section 3 for more details. When the 253 "variables" extension is not enabled the explicit variable name 254 parameter to setflag/addflag/removeflag/hasflag MUST NOT be used 255 and MUST cause an error according to [SIEVE]. 257 2. Conventions used. 259 Conventions for notations are as in [SIEVE] section 1.1, including 260 use of "Usage:" label for the definition of action and tagged 261 arguments syntax. 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in RFC 2119. 267 2.1. General requirements for flag handling 269 The following notes apply to processing of Addflag/Removeflag/Setflag 270 actions, hasflag test and :flags tagged argument. 272 A Sieve interpreter MUST ignore empty strings (i.e. "") in a 273 list-of-flags parameter. 275 A string containing a space-separated list of flag names is 276 equivalent to a string list consisting of the flags. This requirement 277 is to simplify amalgamation of multiple flag lists. 279 The Sieve interpreter SHOULD check the list of flags for validity as 280 described by [IMAP] ABNF. In particular according to [IMAP] non-ASCII 281 characters are not allowed in flag names. However spaces MUST be 282 always allowed as delimiters in strings representing a list of flags. 283 In such strings multiple spaces between flag names MUST be treated as 284 a single space character, leading and trailing spaces MUST be 285 ignored. 287 If a flag validity check fails the flag MUST be ignored. 289 Note that it is not possible to use this extension to set or clear 290 the \Recent flag or any other special system flag which is not 291 settable in [IMAP]. Any such flags MUST be ignored if included in 292 a flag list. 294 3. Actions 296 All actions described in this specification (setflag, addflag, 297 removeflag) operate on string variables that contain a set of [IMAP] 298 flags. On variable substitution a set of flags is represented as 299 a string containing space-separated list of flag names. 301 Any of setflag/addflag/removeflag action MAY alter the flag list in 302 any way that leaves its semantics as a set of case-insensitive words 303 unaltered. For example, it may reorder the flags, alter the case of 304 the letters in them, or add or remove duplicates or extraneous 305 spaces. Scripts MUST NOT make assumptions about the ordering of 306 flags in lists or the preservation of their case. 308 Note that the parameter specifying a variable name to setflag/ 309 addflag/removeflag actions and the hasflag test is optional. If the 310 parameter is not specified the actions operate on the internal 311 variable, which has the empty value when the script starts execution. 312 If the SIEVE interpreter doesn't support the "variables" extension 313 [VARIABLES], the presence of the variable name parameter will cause 314 a runtime error [SIEVE]. 316 The "addflag" action adds flags to an existing set. The "removeflag" 317 action removes flags from an existing set. The "setflag" action 318 replaces an existing set of flags with a new set. The "set" action 319 defined in [VARIABLES] can be used to replace an existing set of 320 flags with a new set as well. However it should be noted that the 321 "set" action can't perform any flag reordering, duplicate 322 elimination, etc. 324 The :flags tagged argument to "keep" and "fileinto" 325 actions is used to associate a set of flags 326 with the current message. If the :flags tagged argument is not 327 specified with those 2 actions, the current value of the internal 328 variable is used instead. The value of the internal variable 329 also applies to the implicit keep. 331 Note that when keep/fileinto is used multiple times in a script and 332 duplicate message elimination is performed (as described in Section 333 2.10.3 of [SIEVE]), the last flag list value MUST win. 335 3.1. Setflag Action 337 Usage: setflag [] 338 340 Setflag is used for setting [IMAP] system flags or keywords. 341 Setflag replaces any previously set flags. 343 Example: if size :over 500K { 344 setflag "\\Deleted"; 345 } 347 A more substantial example is: 349 Example: 350 if header :contains "from" "boss@frobnitzm.example.edu" { 351 setflag "flagvar" "\\Flagged"; 352 fileinto :flags "${flagvar}" "INBOX.From Boss"; 353 } 355 3.2. Addflag action 357 Usage: addflag [] 358 360 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 361 replace any previously set flags. This means that multiple 362 occurrences of addflag are treated additively. 364 The following examples demonstrate requirements described in 2.1. 365 The following two actions 367 addflag "flagvar" "\\Deleted"; 368 addflag "flagvar" "\\Answered"; 370 produce the same result as the single action 372 addflag "flagvar" ["\\Deleted", "\\Answered"]; 374 or 376 addflag "flagvar" "\\Deleted \\Answered"; 378 or 380 addflag "flagvar" "\\Answered \\Deleted"; 382 3.3. Removeflag Action 384 Usage: removeflag [] 385 387 Removeflag is used to remove flags from a list of [IMAP] flags. 388 Removeflag clears flags previously set by "set"/"addflag". Calling 389 removeflag with a flag that wasn't set before is not an error and 390 is ignored. Note, that if an implementation doesn't perform automatic 391 duplicate elimination, it MUST remove all occurences of the flags 392 specified in the second parameter to removeflag. Empty strings in the 393 list-of-flags MUST be ignored. Also note, that flag names are 394 case-insensitive, as described in [IMAP]. 395 Multiple removeflag actions are treated additively. 397 Example: 398 if header :contains "Disposition-Notification-To" 399 "mel@example.com" { 400 addflag "flagvar" "$MDNRequired"; 401 } 402 if header :contains "from" "imap@cac.washington.example.edu" { 403 removeflag "flagvar" "$MDNRequired"; 404 fileinto :flags "${flagvar}" "INBOX.imap-list"; 405 } 407 4. Test hasflag 409 Usage: hasflag [MATCH-TYPE] [COMPARATOR] 410 [] 411 413 The "hasflag" test evaluates to true if any of the variables matches 414 any flag name. The type of match defaults to ":is". 415 If the list of variables is omitted, value of the internal variable 416 is used instead. 418 The default comparator is "i;ascii-casemap", which is the same 419 case-insensitive comparison as defined for IMAP flags by [IMAP]. 421 The "relational" extension [RELATIONAL] adds a match type called 422 ":count". The :count of a variable returns the number of distinct 423 flags in it. The count of a list of variables is the sum of the 424 counts of the member variables. 426 Example: 427 If the internal variable has the value "A B", the following test 429 hasflag :is "b A" 431 evaluates to true. The above test can be also written as 433 hasflag ["b","A"] 435 Example: 436 If the variable "MyVar" has value "NonJunk Junk gnus-forward 437 $Forwarded NotJunk JunkRecorded $Junk $NotJunk", the following 438 tests evaluate to true: 440 hasflag :contains "MyVar" "Junk" 441 hasflag :contains "MyVar" "forward" 442 hasflag :contains "MyVar" ["label", "forward"] 443 hasflag :contains "MyVar" ["junk", "forward"] 445 Note that the last of these tests can be rewritten 446 as 448 hasflag :contains "MyVar" "junk forward" 450 or 452 hasflag :contains "MyVar" "forward junk" 454 However the last two forms are not recommended. 456 And the following tests will evaluate to false: 458 hasflag :contains "MyVar" "label" 460 hasflag :contains "MyVar" ["label1", "label2"] 462 Example: 463 If the variable "MyFlags" has the value "A B", the following test 465 hasflag :count "ge" :comparator "i;ascii-numeric" 466 "MyFlags" "2" 468 evaluates to true, as the variable contains 2 distinct flags. 470 5. Tagged argument :flags 472 This specification adds a new optional tagged argument ":flags" that 473 alter the behavior of actions "keep" and "fileinto". 475 The :flags tagged argument specifies that the flags provided in the 476 subsequent argument should be set when fileinto/keep delivers the 477 message to the target mailbox/user's main mailbox. If the :flags 478 tagged argument is not specified, "keep" or "fileinto" will use 479 the current value of the internal variable when delivering message 480 to the target mailbox. 482 Usage: ":flags" 484 The copy of the message filed into mailbox will have only flags 485 listed after the ":flags" tagged argument. 487 The Sieve interpreter MUST ignore all flags that it can't store 488 permanently. This means that the interpreter MUST NOT treat failure 489 to store any flag as a runtime failure to execute the Sieve 490 script. For example, if the mailbox "INBOX.From Boss" can't store any 491 flags, then 493 fileinto :flags "\\Deleted" "INBOX.From Boss"; 495 and 497 fileinto "INBOX.From Boss"; 499 are equivalent. 501 This document doesn't dictate how the Sieve interpreter will set 502 the [IMAP] flags. In particular, the Sieve interpreter may work as 503 an IMAP client, or may have direct access to the mailstore. 505 6. Interaction with Other Sieve Actions 507 This extension works only on the message that is currently being 508 processed by Sieve, it doesn't affect another message generated 509 as a side effect of any action or any other message already in 510 the mailstore. 512 The extension described in this document doesn't change the implicit 513 keep (see section 2.10.2 of [SIEVE]). 515 7. Security Considerations 517 Security considerations are discussed in the [IMAP], [SIEVE] and 518 [VARIABLES]. 520 This extension intentionally doesn't allow setting [IMAP] flags on 521 an arbitrary message in the [IMAP] message store. 523 It is believed that this extension doesn't introduce any additional 524 security concerns. 526 8. IANA Considerations 528 The following template specifies the IANA registration of the 529 variables Sieve extension specified in this document: 531 To: iana@iana.org 532 Subject: Registration of new Sieve extension 534 Capability name: imap4flags 535 Capability keyword: imap4flags 536 Capability arguments: N/A 537 Standards Track/IESG-approved experimental RFC number: 538 this RFC 539 Person and email address to contact for further information: 540 Alexey Melnikov 541 543 This information should be added to the list of sieve extensions 544 given on http://www.iana.org/assignments/sieve-extensions. 546 9. Extended example 548 # 549 # Example Sieve Filter 550 # Declare any optional features or extension used by the script 551 # 552 require ["fileinto", "imap4flags", "variables"]; 554 # 555 # Move large messages to a special mailbox 556 # 557 if size :over 1M 558 { 559 addflag "MyFlags" "Big"; 560 if header :is "From" "boss@company.example.com" 561 { 562 # The message will be marked as "\Flagged Big" when filed into 563 # mailbox "Big messages" 564 addflag "MyFlags" "\\Flagged"; 565 } 566 fileinto :flags "${MyFlags}" "Big messages"; 567 } 569 if header :is "From" "grandma@example.net" 570 { 571 addflag "MyFlags" ["\\Answered", "$MDNSent"]; 572 # If the message is bigger than 1Mb it will be marked as 573 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 574 # If the message is shorter than 1Mb it will be marked as 575 # "\Answered $MDNSent" 576 fileinto :flags "${MyFlags}" "GrandMa"; 577 } 579 # 580 # Handle messages from known mailing lists 581 # Move messages from IETF filter discussion list to filter folder 582 # 583 if header :is "Sender" "owner-ietf-mta-filters@example.org" 584 { 585 set "MyFlags" "\\Flagged $Work"; 586 # Message will have both "\Flagged" and $Work flags 587 keep :flags "${MyFlags}"; 588 } 590 # 591 # Keep all messages to or from people in my company 592 # 593 elsif anyof address :domain :is ["From", "To"] "company.example.com" 594 { 595 keep :flags "${MyFlags}"; # keep in "Inbox" folder 596 } 597 # 598 # Try and catch unsolicited email. If a message is not to me, 599 # or it contains a subject known to be spam, file it away. 600 # 601 elsif anyof (not address :all :contains 602 ["To", "Cc"] "me@company.example.com", 603 header :matches "subject" 604 ["*make*money*fast*", "*university*dipl*mas*"]) 605 { 606 remove "MyFlags" "\\Flagged"; 607 fileinto :flags "${MyFlags}" "spam"; 608 } 609 else 610 { 611 # Move all other external mail to "personal" 612 # folder. 613 fileinto :flags "${MyFlags}" "personal"; 614 } 616 10. Acknowledgments 618 This document has been revised in part based on comments and 619 discussions which took place on and off the Sieve mailing list. 621 The help of those who took the time to review the draft and make 622 suggestions is appreciated, especially that of Tim Showalter, 623 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 624 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, 625 Kjetil Torgrim Homme, Mark E. Mallett, Dave Cridland, 626 Arnt Gulbrandsen, Philip Guenther, Rob Austein, Sam Hartman, 627 Eric Gray and Cullen Jennings. 629 Special thanks to Tony Hansen and David Lamb for helping me 630 better explain the concept. 632 11. Author's Address 634 Alexey Melnikov 635 Isode Limited 637 5 Castle Business Village 638 Hampton, Middlesex 639 United Kingdom, TW12 2BX 641 Email: alexey.melnikov@isode.com 643 12. Normative References 645 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 646 Language", work in progress, I-D draft-ietf-sieve-3028bis. 648 [KEYWORDS] Bradner, S., "Keywords for use in RFCs to Indicate 649 Requirement Levels", Harvard University, RFC 2119, March 1997. 651 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 652 4rev1", University of Washington, RFC 3501, March 2003. 654 [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University 655 of Oslo, work in progress, draft-ietf-sieve-variables-XX.txt 657 [RELATIONAL] Leiba, B. and Segmuller, W., "Sieve Extension: 658 Relational Tests", Work in Progress, draft-ietf-sieve-3431bis-XX.txt 660 13. Intellectual Property Statement 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed 664 to pertain to the implementation or use of the technology 665 described in this document or the extent to which any license 666 under such rights might or might not be available; nor does it 667 represent that it has made any independent effort to identify any 668 such rights. Information on the procedures with respect to rights 669 in RFC documents can be found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use 674 of such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository 676 at http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention 679 any copyrights, patents or patent applications, or other 680 proprietary rights that may cover technology that may be required 681 to implement this standard. Please address the information to the 682 IETF at ietf-ipr@ietf.org. 684 14. Full Copyright Statement 686 Copyright (C) The Internet Society (2006). 688 This document is subject to the rights, licenses and restrictions 689 contained in BCP 78, and except as set forth therein, the authors 690 retain all their rights. 692 This document and the information contained herein are provided on 693 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 694 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 695 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 696 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 697 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 698 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 699 PARTICULAR PURPOSE. 701 Acknowledgement 703 Funding for the RFC Editor function is currently provided by the 704 Internet Society.