idnits 2.17.1 draft-ietf-sieve-imapflags-04.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 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 643. ** 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 700 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. ** The abstract seems to contain references ([IMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2006) is 6644 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 371, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 371, but not defined ** 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: 6 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-04.txt Isode Limited 4 Expires: August 2006 February 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] flags on message delivery. This can be done, for example, 34 by a Sieve interpreter that works as a part of a Mail Delivery 35 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 1. Introduction 207 This is an extension to the Sieve language defined by [SIEVE] for 208 setting [IMAP] flags. It adds a new tagged argument to "keep" and 209 "fileinto" that describes the list of flags that have to be set 210 when the message is delivered to the specified mailbox. It also 211 adds several actions to help manipulate list of flags and a test 212 to check if a flag belongs to a list. 214 The capability string associated with extension defined in this 215 document is "imap4flags". 217 The "imap4flags" extension can be used with or without the 218 "variables" extension [VARIABLES]. When the "variables" extension 219 is enabled in a script using , the script can 220 use explicit variable names in setflag/addflag/removeflag actions 221 and hasflag test. See also section 3 for more details. When the 222 "variables" extension is not enabled the explicit variable name 223 parameter to setflag/addflag/removeflag/hasflag MUST NOT be used 224 and MUST cause an error according to [SIEVE]. 226 2. Conventions used. 228 Conventions for notations are as in [SIEVE] section 1.1, including 229 use of [KEYWORDS] and "Usage:" label for the definition of action 230 and tagged arguments syntax. 232 2.1. General requirements for flag handling 234 The following notes apply to processing of Addflag and Removeflag 235 actions, hasflag test and :flags tagged argument. 237 A Sieve interpreter MUST ignore empty strings (i.e. "") in a 238 list-of-flags parameter. 240 The Sieve interpreter SHOULD check the list of flags for validity as 241 described by [IMAP] ABNF. In particular non-ASCII characters are not 242 allowed in flag names. However spaces MUST be always allowed. 243 Multiple spaces between flag names MUST be treated as a single space 244 character, leading and trailing spaces MUST be ignored. 245 A string containing a space-separated list of flags is equivalent to 246 a string list consisting of the flags. The last requirement is to 247 simplify amalgamation of multiple flag lists. 249 If a flag validity check fails the flag MUST be ignored. 251 Note that it is not possible to use this extension to set or clear 252 the \Recent flag or any other special system flag which is not 253 settable in [IMAP]. Any such flags MUST be ignored if included in 254 a flag list. 256 3. Actions 258 All actions described in this specification (setflag, addflag, 259 removeflag) operate on string variables that contain a set of [IMAP] 260 flags. On variable substitution a set of flags is represented as 261 a string containing space-separated list of flag names. 263 Any of setflag/addflag/removeflag action MAY alter the flag list in 264 any way that leaves its semantics as a set of case-insensitive words 265 unaltered. For example, it may reorder the flags, alter the case of 266 the letters in them, or add or remove duplicates or extraneous 267 spaces. Scripts MUST NOT make assumptions about the ordering of 268 flags in lists or the preservation of their case. 270 Note that the parameter specifying a variable name to setflag/ 271 addflag/removeflag actions and the hasflag test is optional. If the 272 parameter is not specified the actions operate on the internal 273 variable, which has the empty value when the script starts execution. 274 If the SIEVE interpreter doesn't support the "variables" extension 275 [VARIABLES], the presence of the variable name parameter MUST cause 276 runtime error. 278 The "addflag" action adds flags to an existing set. The "removeflag" 279 action removes flags from an existing set. The "setflag" action 280 replaces an existing set of flags with a new set. The "set" action 281 defined in [VARIABLES] can be used to replace an existing set of 282 flags with a new set as well. However it should be noted that the 283 "set" action can't perform any flag reordering, duplicate 284 elimination, etc. 286 The :flags tagged argument to "keep" and "fileinto" 287 actions is used to associate a set of flags 288 with the current message. If the :flags tagged argument is not 289 specified with those 2 actions, the current value of the internal 290 variable is used instead. The value of the internal variable 291 also applies to the implicit keep. 293 Note that when keep/fileinto is used multiple times in a script and 294 duplicate message elimination is performed, the last flag list value 295 MUST win. 297 3.1. Setflag Action 299 Usage: setflag [] 300 302 Setflag is used for setting [IMAP] system flags or keywords. 303 Setflag replaces any previously set flags. 305 Example: if size :over 500K { 306 setflag "flags" "\\Deleted"; 307 } 309 A more substantial example is: 311 Example: 312 if header :contains "from" "boss@frobnitzm.example.edu" { 313 setflag "flagvar" "\\Flagged"; 314 fileinto :flags "${flagvar}" "INBOX.From Boss"; 315 } 317 3.2. Addflag action 319 Usage: addflag [] 320 322 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 323 replace any previously set flags. This means that multiple 324 occurrences of addflag are treated additively. 326 The following examples demonstrate requirements described in 2.1. 327 The following two actions 329 addflag "flagvar" "\\Deleted"; 330 addflag "flagvar" "\\Answered"; 332 produce the same result as the single action 334 addflag "flagvar" ["\\Deleted", "\\Answered"]; 336 or 338 addflag "flagvar" "\\Deleted \\Answered"; 340 or 342 addflag "flagvar" "\\Answered \\Deleted"; 344 3.3. Removeflag Action 346 Usage: removeflag [] 347 349 Removeflag is used to remove flags from a list of [IMAP] flags. 350 Removeflag clears flags previously set by "set"/"addflag". Calling 351 removeflag with a flag that wasn't set before is not an error and 352 is ignored. Note, that if an implementation doesn't perform automatic 353 duplicate elimination, it MUST remove all occurences of the flags 354 specified in the second parameter to removeflag. Empty strings in the 355 list-of-flags MUST be ignored. Also note, that flag names are 356 case-insensitive, as described in [IMAP]. 357 Multiple removeflag actions are treated additively. 359 Example: 360 if header :contains "Disposition-Notification-To" 361 "mel@example.com" { 362 addflag "flagvar" "$MDNRequired"; 363 } 364 if header :contains "from" "imap@cac.washington.example.edu" { 365 removeflag "flagvar" "$MDNRequired"; 366 fileinto :flags "${flagvar}" "INBOX.imap-list"; 367 } 369 4. Test hasflag 371 Usage: hasflag [MATCH-TYPE] [COMPARATOR] 372 [] 373 375 The "hasflag" test evaluates to true if any of the variables matches 376 any flag name. The type of match defaults to ":is". 377 If the list of variables is omitted, value of the internal variable 378 is used instead. 380 The default comparator is "i;ascii-casemap", which is the same 381 case-insensitive comparison as defined for IMAP flags by [IMAP]. 383 The "relational" extension [RELATIONAL] adds a match type called 384 ":count". The :count of a variable returns the number of distinct 385 flags in it. The count of a list of variables is the sum of the 386 counts of the member variables. 388 Example: 389 If the variable "MyFlags" has the value "A B", the following test 391 hasflag :is "MyFlags" "b A" 393 evaluates to true. The above test can be also written as 395 hasflag "MyFlags" ["b","A"] 397 Example: 398 If the variable "MyVar" has value "NonJunk Junk gnus-forward 399 $Forwarded NotJunk JunkRecorded $Junk $NotJunk", the following 400 tests evaluate to true: 402 hasflag :contains "MyVar" "Junk" 403 hasflag :contains "MyVar" "forward" 404 hasflag :contains "MyVar" ["label", "forward"] 405 hasflag :contains "MyVar" ["junk", "forward"] 407 Note that the last of these tests can be rewritten 408 as 410 hasflag :contains "MyVar" "junk forward" 412 or 414 hasflag :contains "MyVar" "forward junk" 416 However the last two forms are not recommended. 418 And the following test will evaluate to false: 420 hasflag :contains "MyVar" "label" 422 hasflag :contains "MyVar" "label" 424 Example: 425 If the variable "MyFlags" has the value "A B", the following test 427 hasflag :count "ge" :comparator "i;ascii-numeric" 428 "MyFlags" "2" 430 evaluates to true, as the variable contains 2 distinct flags. 432 5. Tagged argument :flags 434 This specification adds a new optional tagged argument ":flags" that 435 alter the behavior of actions "keep" and "fileinto". 437 The :flags tagged argument specifies that the flags provided in the 438 subsequent argument should be set when fileinto/keep delivers the 439 message to the target mailbox/user's main mailbox. If the :flags 440 tagged argument is not specified, "keep" or "fileinto" will use 441 the current value of the internal variable when delivering message 442 to the target mailbox. 444 Usage: ":flags" 446 The copy of the message filed into mailbox will have only flags 447 listed after the ":flags" tagged argument. 449 The Sieve interpreter MUST ignore all flags that it can't store 450 permanently. This means that the interpreter MUST NOT treat failure 451 to store any flag as a runtime failure to execute the Sieve 452 script. For example, if the mailbox "INBOX.From Boss" can't store any 453 flags, then 455 fileinto :flags "\\Deleted" "INBOX.From Boss"; 457 and 459 fileinto "INBOX.From Boss"; 461 are equivalent. 463 This document doesn't dictate how the Sieve interpreter will set 464 the [IMAP] flags. In particular, the Sieve interpreter may work as 465 an IMAP client, or may have direct access to the mailstore. 467 6. Interaction with Other Sieve Actions 469 This extension works only on the message that is currently being 470 processed by Sieve, it doesn't affect another message generated 471 as a side affect of any action. 473 The extension decribed in this document doesn't change the implicit 474 keep (see section 2.10.2 of [SIEVE]). 476 7. Other Considerations 478 This extension intentionally doesn't allow setting [IMAP] flags on 479 an arbitrary message in the [IMAP] message store. 481 8. Security Considerations 483 Security considerations are discussed in the [IMAP], [SIEVE] and 484 [VARIABLES]. 485 It is believed that this extension doesn't introduce any additional 486 security concerns. 488 9. IANA Considerations 490 The following template specifies the IANA registration of the 491 variables Sieve extension specified in this document: 493 To: iana@iana.org 494 Subject: Registration of new Sieve extension 496 Capability name: imap4flags 497 Capability keyword: imap4flags 498 Capability arguments: N/A 499 Standards Track/IESG-approved experimental RFC number: 500 this RFC 501 Person and email address to contact for further information: 502 Alexey Melnikov 503 505 This information should be added to the list of sieve extensions 506 given on http://www.iana.org/assignments/sieve-extensions. 508 10. Extended example 510 # 511 # Example Sieve Filter 512 # Declare any optional features or extension used by the script 513 # 514 require ["fileinto", "imap4flags", "variables"]; 516 # 517 # Move large messages to a special mailbox 518 # 519 if size :over 1M 520 { 521 addflag "MyFlags" "Big"; 522 if header :is "From" "boss@company.example.com" 523 { 524 # The message will be marked as "\Flagged Big" when filed into 525 # mailbox "Big messages" 526 addflag "MyFlags" "\\Flagged"; 527 } 528 fileinto :flags "${MyFlags}" "Big messages"; 529 } 531 if header :is "From" "grandma@example.net" 532 { 533 addflag "MyFlags" ["\\Answered", "$MDNSent"]; 534 # If the message is bigger than 1Mb it will be marked as 535 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 536 # If the message is shorter than 1Mb it will be marked as 537 # "\Answered $MDNSent" 538 fileinto :flags "${MyFlags}" "GrandMa"; 539 } 541 # 542 # Handle messages from known mailing lists 543 # Move messages from IETF filter discussion list to filter folder 544 # 545 if header :is "Sender" "owner-ietf-mta-filters@example.org" 546 { 547 set "MyFlags" "\\Flagged $Work"; 548 # Message will have both "\Flagged" and $Work flags 549 keep :flags "${MyFlags}"; 550 } 552 # 553 # Keep all messages to or from people in my company 554 # 555 elsif anyof address :domain :is ["From", "To"] "company.example.com" 556 { 557 keep :flags "${MyFlags}"; # keep in "Inbox" folder 558 } 559 # 560 # Try and catch unsolicited email. If a message is not to me, 561 # or it contains a subject known to be spam, file it away. 562 # 563 elsif anyof (not address :all :contains 564 ["To", "Cc"] "me@company.example.com", 565 header :matches "subject" 566 ["*make*money*fast*", "*university*dipl*mas*"]) 567 { 568 remove "MyFlags" "\\Flagged"; 569 fileinto :flags "${MyFlags}" "spam"; 570 } 571 else 572 { 573 # Move all other external mail to "personal" 574 # folder. 575 fileinto :flags "${MyFlags}" "personal"; 576 } 578 11. Acknowledgments 580 This document has been revised in part based on comments and 581 discussions which took place on and off the Sieve mailing list. 583 The help of those who took the time to review the draft and make 584 suggestions is appreciated, especially that of Tim Showalter, 585 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 586 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, 587 Kjetil Torgrim Homme, Mark E. Mallett, Dave Cridland, 588 Arnt Gulbrandsen and Philip Guenther. 590 Special thanks to Tony Hansen and David Lamb for helping me 591 better explain the concept. 593 12. Author's Address 595 Alexey Melnikov 596 Isode Limited 598 5 Castle Business Village 599 Hampton, Middlesex 600 United Kingdom, TW12 2BX 602 Email: alexey.melnikov@isode.com 604 13. Normative References 606 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 607 Language", work in progress, I-D draft-ietf-sieve-3028bis. 609 [KEYWORDS] Bradner, S., "Keywords for use in RFCs to Indicate 610 Requirement Levels", Harvard University, RFC 2119, March 1997. 612 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 613 4rev1", University of Washington, RFC 3501, March 2003. 615 [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University 616 of Oslo, work in progress, draft-ietf-sieve-variables-XX.txt 618 [RELATIONAL] Leiba, B. and Segmuller, W., "Sieve Extension: 619 Relational Tests", Work in Progress, draft-ietf-sieve-3431bis-XX.txt 621 14. Intellectual Property Statement 623 The IETF takes no position regarding the validity or scope of any 624 Intellectual Property Rights or other rights that might be claimed 625 to pertain to the implementation or use of the technology 626 described in this document or the extent to which any license 627 under such rights might or might not be available; nor does it 628 represent that it has made any independent effort to identify any 629 such rights. Information on the procedures with respect to rights 630 in RFC documents can be found in BCP 78 and BCP 79. 632 Copies of IPR disclosures made to the IETF Secretariat and any 633 assurances of licenses to be made available, or the result of an 634 attempt made to obtain a general license or permission for the use 635 of such proprietary rights by implementers or users of this 636 specification can be obtained from the IETF on-line IPR repository 637 at http://www.ietf.org/ipr. 639 The IETF invites any interested party to bring to its attention 640 any copyrights, patents or patent applications, or other 641 proprietary rights that may cover technology that may be required 642 to implement this standard. Please address the information to the 643 IETF at ietf-ipr@ietf.org. 645 15. Full Copyright Statement 647 Copyright (C) The Internet Society (2006). 649 This document is subject to the rights, licenses and restrictions 650 contained in BCP 78, and except as set forth therein, the authors 651 retain all their rights. 653 This document and the information contained herein are provided on 654 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 655 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 656 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 657 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 658 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 659 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 660 PARTICULAR PURPOSE. 662 Acknowledgement 664 Funding for the RFC Editor function is currently provided by the 665 Internet Society.