idnits 2.17.1 draft-ietf-sieve-variables-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 656), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 629. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. == 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 (14 Jul 2005) is 6858 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MODIFIER' is mentioned on line 374, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 492, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 492, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3431 (ref. 'RELATIONAL') (Obsoleted by RFC 5231) ** Obsolete normative reference: RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 3685 (ref. 'SPAMTEST') (Obsoleted by RFC 5235) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. T. Homme 3 Updates: 3028 4 Document: draft-ietf-sieve-variables-04.txt University of Oslo 5 Expires Jan 14, 2006 14 Jul 2005 7 Sieve Mail Filtering Language: Variables Extension 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3978. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she becomes aware will be disclosed, in accordance with 16 Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Abstract 38 In advanced filtering rule sets, it is useful to keep state or 39 configuration details across rules. This extension changes the 40 interpretation of strings, adds an action to store data in variables, 41 and supplies a new test so that the value of a string can be 42 examined. 44 0. Meta-information on this draft 46 This information is intended to facilitate discussion. It will be 47 removed when this document leaves the Internet-Draft stage. 49 0.1. Discussion 51 This draft is intended to be an extension to the Sieve mail filtering 52 language, available from the RFC repository as 53 . 55 This draft and the Sieve language itself are being discussed on the 56 MTA Filters mailing list at . Subscription 57 requests can be sent to (send an 58 email message with the word "subscribe" in the body). More 59 information on the mailing list along with a WWW archive of back 60 messages is available at . 62 0.2. Noted Changes 64 0.2.1. Changes since -00 66 a) allow generic time zone names, without requiring implementations to 67 support it. added a "${timezone}" variable so that the user can 68 check if the implementation does support the time zone name he 69 wants. the default time zone was changed to localtime again. 71 b) allow back references from :matches as well as :regex. 73 c) added a section on implementation limits. 75 d) clarified global scope so that it spans include. 77 e) clarified that this draft only affects scripts which require 78 "variables". 80 f) changed modifiers into being tagged arguments for SET, added 81 precedence table. 83 g) added optional COMPARATOR to SET to solve the internationalisation 84 problem with :lower etc. 86 h) the name of the variable being SET is passed in a string to conform 87 with overall Sieve grammar. this string is explicitly disallowed 88 from containing variable references. 90 0.2.2. Changes since -01 92 a) clarify that a character is a Unicode character. 94 b) added paragraph warning against relying on Sieve for virus checking 95 to security section. 97 c) added a paragraph defining constant string. 99 d) added namespace to grammar. 101 e) removed SETDATE. 103 f) added wording and example requiring short-circuiting of test 104 evaluation. 106 0.2.3. Changes since -02 108 a) add references to Unicode and UTF-8, also more boilerplate 110 b) fixed a meaningless example. 112 c) changed term "numeric variables" to "numbered variables" to reduce 113 the chance of it being interpreted as variables holding integer 114 values. 116 d) allow future extensions to access the raw string value. 118 e) an unsuccessful match does NOT reset the numbered variables. 120 f) added definition of "string :count" 122 g) exceeding implementation limits on variable lengths should not make 123 scripts abort. 125 0.2.4. Changes since -03 127 a) clarify short-circuiting. 129 b) editorial changes. 131 0.2.5. Changes since -04 133 a) the wildcards in :matches was changed from greedy to non-greedy to 134 better support "principle of least surprise". added example to 135 illustrate the difference. 137 b) add definition of "variable"; clarify grammar is based on [SIEVE]; 138 clarify role of namespaces; add informative references for [REGEX] 139 and [SPAMTEST]; add normative reference for [RELATIONAL] 141 c) the use of unsupported numbered variables must be flagged as a 142 syntax error by implementations. 144 0.2.6. Changes since -00 (WG series) 146 a) added example for string test 148 b) moved introductory text for MODIFIER from 5.1 into 5.0 150 c) added Syntax line for MODIFIER. 152 d) added comment to an example showing that the non-greedy "*" still 153 matches everything due to implicit anchors. 155 e) added example of expansion of string with unbalanced braces. 157 f) updated reference to [SPAMTEST]. 159 0.2.7. Changes since -01 161 a) moved References from appendix into the document itself. 163 b) added example of SET with a comparator. 165 c) changed "highest value" to the less ambiguous "largest value". 167 d) updated reference to [UTF-8]. 169 e) allow numbered variables in namespaces. 171 f) change ${0} to mean the complete match. 173 0.2.8. Changes since -02 175 a) explicitly state compatibility with actions in base spec. 177 b) "numbered variables" are now called "match variables". 179 c) clarify definition of "match variable". 181 d) it's not the whole namespace which should match the extension 182 keyword, only the first component. 184 e) allow level 2 and above of the namespace specification to be all- 185 digit. 187 f) combining :upper and :lower etc. is a now syntax error. 189 g) allow SET to set variables in namespaces if the extension allows 190 it. 192 0.2.9. Changes since -03 194 a) added two new modifiers, ":quoteregex" and ":quotewildcard". 196 b) added wording about security implications of silent truncation. 198 0.3. Open Issues 200 This extension is in conflict with a MUST in [SIEVE] 2.4: "Tests MUST 201 NOT have side effects." This document therefore can't leave draft 202 status until a revised Sieve specification has been accepted by the 203 IESG. No significant changes to this draft are foreseen before 204 submission as a proposed standard. 206 1. Introduction 208 This is an extension to the Sieve language defined by [SIEVE]. It 209 adds support for storing and referencing named data. The mechanisms 210 detailed in this document will only apply to Sieve scripts that 211 include a require clause for the "variables" extension. The require 212 clauses themselves are not affected by this extension. 214 Conventions for notations are as in [SIEVE] section 1.1, including 215 use of [KEYWORDS] and [ABNF]. The grammar builds on the grammar of 216 [SIEVE]. In this document, "character" means a [UNICODE] character, 217 which may consist of multiple octets coded in [UTF-8], and "variable" 218 is a named reference to data stored or read back using the mechanisms 219 of this extension. 221 2. Capability Identifier 223 The capability string associated with the extension defined in this 224 document is "variables". 226 3. Interpretation of strings 228 This extension changes the semantics of quoted-string, multi-line- 229 literal and multi-line-dotstuff found in [SIEVE] to enable the 230 inclusion of the value of variables. 232 When a string is evaluated, substrings matching variable-ref SHALL be 233 replaced by the value of variable-name. Only one pass through the 234 string SHALL be done. Variable names are case insensitive, so "foo" 235 and "FOO" refer to the same variable. Unknown variables are replaced 236 by the empty string. 238 variable-ref = "${" [namespace] variable-name "}" 239 namespace = identifier "." *sub-namespace 240 sub-namespace = variable-name "." 241 variable-name = num-variable / identifier 242 num-variable = 1*DIGIT 244 Examples: 245 "&%${}!" => unchanged, as the empty string is an illegal 246 identifier 247 "${doh!}" => unchanged, as "!" is illegal in identifiers 249 The variable "company" holds the value "ACME". No other variables 250 are set. 252 "${full}" => the empty string 253 "${company}" => "ACME" 254 "${President, ${Company} Inc.}" 255 => "${President, ACME Inc.}" 256 "${BAD${Company}"=>"${BADACME" 258 The expanded string MUST use the variable values which are current 259 when control reaches the statement the string is part of. 261 Strings where no variable substitutions take place are referred to as 262 constant strings. Future extensions may specify that passing non- 263 constant strings as arguments to its actions or tests is an error. 265 Namespaces are meant for future extensions which make internal state 266 available through variables. These variables SHOULD be put in a 267 namespace whose first component is the same as its capability string. 269 Such extensions SHOULD state which, if any, of the variables in its 270 namespace are modifiable with the "set" action. 272 References to namespaces without a prior require statement for the 273 relevant extension MUST cause a syntax error. 275 Tests or actions in future extensions may need to access the 276 unexpanded version of the string argument and, e.g., do the expansion 277 after setting variables in its namespace. The design of the 278 implementation should allow this. 280 3.1. Quoting 282 The semantics of quoting using backslash are not changed: backslash 283 quoting is resolved before doing variable substitution. 285 Examples: 286 "${fo\o}" => ${foo} => the expansion of variable foo. 287 "${fo\\o}" => ${fo\o} => illegal identifier => left verbatim. 288 "\${foo}" => ${foo} => the expansion of variable foo. 289 "\\${foo}" => \${foo} => a backslash character followed by the 290 expansion of variable foo. 292 If it is required to include a character sequence such as "${beep}" 293 verbatim in a text literal, the user can define a variable to 294 circumvent expansion to the empty string. 296 Example: 297 set "dollar" "$"; 298 set "text" "regarding ${dollar}{beep}"; 300 3.2. Match variables 302 A "match variable" has a name consisting only of decimal digits and 303 has no namespace component. 305 The decimal value of the match variable name will index the list of 306 matching strings from the most recently evaluated successful match of 307 type ":matches" or ":regex" (see [REGEX]). The list is empty if no 308 match has been successful. 310 For ":matches", the list will contain one string for each wildcard 311 ("?" and "*") in the match pattern. Each string holds what the 312 corresponding wildcard expands to, possibly the empty string. The 313 wildcards match as little as possible (non-greedy matching). 315 For ":regex", the list will contain the strings corresponding to the 316 group operators. The groups are ordered by the position of the 317 opening parenthesis, from left to right. Note that in regular 318 expressions, expansions match as much as possible (greedy matching). 320 The first string in the list has index 1. If the index is out of 321 range, the empty string will be substituted. Index 0 contains the 322 matched part of the source value. 324 The interpreter MUST short-circuit tests, ie. not perform more tests 325 than necessary to find the result. Evaluation order MUST be left to 326 right. If a test has two or more list arguments, the implementation 327 is free to choose which to iterate over first. 329 Example: 331 require ["fileinto", "regex", "variables"]; 333 if header :regex "List-ID" "<(.*)@" { 334 fileinto "lists.${1}"; stop; 335 } 337 # This usually gives the same result as the above 338 if header :matches "List-ID" "*<*@*" { 339 fileinto "lists.${2}"; stop; 340 } 342 # Imagine the header 343 # Subject: [acme-users] [fwd] version 1.0 is out 344 if header :regex "Subject" "^[(.*)] (.*)$" { 345 # ${1} will hold "acme-users] [fwd" 346 stop; 347 } 348 if header :matches "Subject" "[*] *" { 349 # ${1} will hold "acme-users", 350 # ${2} will hold "[fwd] version 1.0 is out" 351 fileinfo "lists.${1}"; stop; 352 } 354 if address :matches ["To", "Cc"] ["coyote@**.com", 355 "wile@**.com"] { 356 # ${0} is the matching address. 357 # ${1} is always the empty string. 358 fileinto "business.${2}"; stop; 359 } else { 360 # Control wouldn't reach this block if any match was 361 # successful, so no match variables are set at this 362 # point. 364 } 366 if anyof (true, address :domain :matches "To" "*.com") { 367 # The second test is never evaluated, so there are 368 # still no match variables set. 369 stop; 370 } 372 4. Action set 374 Syntax: set [MODIFIER] [COMPARATOR] 376 The "set" action stores the specified value in the variable 377 identified by name. The name MUST be a constant string and conform 378 to the syntax of variable-name. Match variables can not be set. A 379 namespace can not be used unless an extension explicitly allows its 380 use in "set". An invalid name MUST be detected as a syntax error. 382 Modifiers are applied on a value before it is stored in the variable. 383 See next section for details. 385 The default comparator is "i;ascii-casemap". The comparator only 386 affects the result when certain modifiers are used. 388 All variables have global scope: they are visible until processing 389 stops. Variable names are case insensitive. 391 Example: 392 set "honorific" "Mr"; 393 set "first_name" "Wile"; 394 set "last_name" "Coyote"; 395 set "vacation" text: 396 Dear ${HONORIFIC} ${last_name}, 397 I'm out, please leave a message after the meep. 398 . 399 ; 401 "set" does not affect the implicit keep. It is compatible with all 402 actions defined in [SIEVE]. 404 4.1. Modifiers 406 Syntax: ":lower" / ":upper" / ":lowerfirst" / ":upperfirst" / 407 ":length" 409 Modifier names are case insensitive. Unknown modifiers MUST yield a 410 syntax error. More than one modifier can be specified, in which case 411 they are applied according to this precedence list, largest value 412 first: 414 +--------------------------------+ 415 | Precedence Modifier | 416 +--------------------------------+ 417 | 40 :lower | 418 | :upper | 419 +--------------------------------+ 420 | 30 :lowerfirst | 421 | :upperfirst | 422 +--------------------------------+ 423 | 20 :quotewildcard | 424 | :quoteregex | 425 +--------------------------------+ 426 | 10 :length | 427 +--------------------------------+ 429 Using two or more modifiers of the same precedence is a syntax error. 431 Examples: 432 # The value assigned to the variable is printed after the arrow 433 set "a" "juMBlEd lETteRS"; => "juMBlEd lETteRS" 434 set :length "b" "${a}"; => "15" 435 set :lower "b" "${a}"; => "jumbled letters" 436 set :lower :comparator "i;octet" 437 "b" "${a}"; => "juMBlEd lETteRS" 438 set :upperfirst "b" "${a}"; => "JuMBlEd lETteRS" 439 set :upperfirst :lower "b" "${a}"; => "Jumbled letters" 440 set :quotewildcard "b" "Rock*"; => "Rock\*" 442 4.1.1. Modifier ":length" 444 The value is the decimal number of characters in the expansion, 445 converted to a string. 447 4.1.2. Quoting modifiers 449 These modifiers add the necessary quotes to ensure that the expanded 450 text will only match a literal occurence if used as a parameter for 451 :matches or :regex. 453 4.1.2.1. Modifier ":quotewildcard" 455 Every character with special meaning for :matches ("*", "?" and " is 456 prefixed with " 458 4.1.2.2. Modifier ":quoteregex" 460 Every character with special meaning for :regex (".", "*", "?" etc.) 461 is prefixed with " 463 4.1.3. Case modifiers 465 These modifiers change the letters of the text from upper to lower 466 case or vice versa. The implementation MUST support US-ASCII, but is 467 not required to handle the entire Unicode repertoire. The comparator 468 specified SHOULD be consulted to establish which locale to use. 470 4.1.3.1. Modifier ":upper" 472 All lower case letters are converted to their upper case counterpart. 474 4.1.3.2. Modifier ":lower" 476 All upper case letters are converted to their lower case counterpart. 478 4.1.3.3. Modifier ":upperfirst" 480 The first character of the string is converted to upper case if it is 481 a letter and set in lower case. The rest of the string is left 482 unchanged. 484 4.1.3.4. Modifier ":lowerfirst" 486 The first character of the string is converted to lower case if it is 487 a letter and set in upper case. The rest of the string is left 488 unchanged. 490 5. Test string 492 Syntax: string [MATCH-TYPE] [COMPARATOR] 493 495 The "string" test evaluates to true if any of the source strings 496 matches any key. The type of match defaults to ":is". 498 Example: 499 set "state" "${state} pending"; 500 if string :matches " ${state} " "* pending *" { 501 # the above test always succeeds 502 } 504 The "relational" extension [RELATIONAL] adds a match type called 505 ":count". The count of a single string is 0 if it is the empty 506 string, or 1 otherwise. The count of a string list is the sum of the 507 counts of the member strings. 509 6. Implementation Limits 511 An implementation of this draft MUST support at least 128 distinct 512 variables. The supported length of variable names MUST be at least 513 32 characters. Each variable MUST be able to hold at least 4000 514 characters. Attempts to set the variable to a value larger than what 515 the implementation supports SHOULD be reported as an error at 516 compile-time if possible. If the attempt is discovered during run- 517 time, the value SHOULD be truncated and it MUST NOT be treated as an 518 error. 520 Match variables ${1} through ${9} MUST be supported. References to 521 higher indices than the implementation supports MUST be treated as a 522 syntax error which SHOULD be discovered at compile-time. 524 7. Security Considerations 526 When match variables are used, and the author of the script isn't 527 careful, strings can contain arbitrary values controlled by the 528 sender of the e-mail. 530 Since values stored by SET exceeding implementation limits are 531 silently truncated, it's not appropriate to store large structures 532 with security implications in variables. 534 The introduction of variables makes advanced decision making easier 535 to write, but since no looping construct is provided, all Sieve 536 scripts will terminate in an orderly manner. 538 Sieve filtering should not be relied on as a security measure against 539 hostile e-mail messages. Sieve is designed to do simple, mostly 540 static tests, and is not suitable for use as a spam or virus checker, 541 where the perpetrator has a motivation to vary the format of the 542 email in order to avoid filtering rules. See also [SPAMTEST]. 544 8. IANA Considerations 546 The following template specifies the IANA registration of the 547 variables Sieve extension specified in this document: 549 To: iana@iana.org 550 Subject: Registration of new Sieve extension 552 Capability name: variables 553 Capability keyword: variables 554 Capability arguments: N/A 555 Standards Track/IESG-approved experimental RFC number: this RFC 556 Person and email address to contact for further information: 558 Kjetil Torgrim Homme 559 University of Oslo 560 Pb 1080, Blindern 561 NO-0316 OSLO 563 E-mail: kjetilho@ifi.uio.no 565 This information should be added to the list of sieve extensions 566 given on http://www.iana.org/assignments/sieve-extensions. 568 9. Acknowledgments 570 Thanks to Cyrus Daboo, Jutta Degener, Ned Freed, Lawrence Greenfield, 571 Jeffrey Hutzelman, Mark E. Mallett, Alexey Melnikov, Peder Stray and 572 Nigel Swinson for valuable feedback. 574 10. Author's Address 576 Kjetil T. Homme 577 University of Oslo 578 PO Box 1080 579 0316 Oslo, Norway 581 Phone: +47 9366 0091 582 E-mail: kjetilho@ifi.uio.no 584 11. References 586 11.1. Normative references 588 [ABNF] Crocker, D. and Overell, P., "Augmented BNF for Syntax 589 Specifications: ABNF", RFC 2234, November 1997 591 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", RFC 2119, March 1997. 594 [RELATIONAL] Segmuller, W., "Sieve Extension: Relational Tests", 595 RFC 3431, December 2002 597 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 598 3028, January 2001. 600 [UNICODE] The Unicode Consortium, "The Unicode Standard -- 601 Worldwide Character Encoding -- Version 1.0", Addison- 602 Wesley, Volume 1, 1991, Volume 2, 1992. 604 [UTF-8] Yergeau, F., "UTF-8, a transformation format of 605 Unicode and ISO 10646", RFC 3629, November 2003. 607 11.2. Informative References 609 [REGEX] K. Murchison, "Sieve Email Filtering -- Regular 610 Expression Extension", Work in Progress. 612 [SPAMTEST] C. Daboo, "SIEVE Email Filtering: Spamtest and 613 VirusTest Extensions", RFC 3685, February 2004 615 Appendix B. Intellectual Property Rights Statement 617 The IETF takes no position regarding the validity or scope of any 618 intellectual property or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; neither does it represent that it 622 has made any effort to identify any such rights. Information on the 623 IETF's procedures with respect to rights in standards-track and 624 standards-related documentation can be found in BCP-11. Copies of 625 claims of rights made available for publication and any assurances of 626 licenses to be made available, or the result of an attempt made to 627 obtain a general license or permission for the use of such 628 proprietary rights by implementors or users of this specification can 629 be obtained from the IETF Secretariat. 631 Appendix C. Full Copyright Statement 633 Copyright (C) The Internet Society (2005). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at ietf- 669 ipr@ietf.org. 671 Acknowledgement 673 Funding for the RFC Editor function is currently provided by the 674 Internet Society.