idnits 2.17.1 draft-ietf-sieve-variables-08.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 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 696. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 683), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 656. ** 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 (18 Dec 2005) is 6697 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 410, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 515, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 515, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-ietf-sieve-3431bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RELATIONAL' -- No information found for draft-ietf-sieve-3028bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SIEVE' -- Obsolete informational reference (is this intentional?): RFC 3685 (ref. 'SPAMTEST') (Obsoleted by RFC 5235) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 14 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-08.txt University of Oslo 5 Expires Jun 18, 2006 18 Dec 2005 7 Sieve Extension: Variables 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 mail filtering rule sets, it is useful to keep state or 39 configuration details across rules. This document updates the Sieve 40 filtering language (RFC 3028) with an extension to support variables. 41 The extension changes the interpretation of strings, adds an action 42 to store data in variables, and supplies a new test so that the value 43 of a string can be examined. 45 0. Meta-information on this draft 47 This information is intended to facilitate discussion. It will be 48 removed when this document leaves the Internet-Draft stage. 50 0.1. Discussion 52 This draft is intended to be an extension to the Sieve mail filtering 53 language, available from the RFC repository as 54 . 56 This draft and the Sieve language itself are being discussed on the 57 MTA Filters mailing list at . Subscription 58 requests can be sent to (send an 59 mail message with the word "subscribe" in the body). More 60 information on the mailing list along with a WWW archive of back 61 messages is available at . 63 0.2. Noted Changes 65 0.2.1. Changes since -00 67 a) allow generic time zone names, without requiring implementations to 68 support it. added a "${timezone}" variable so that the user can 69 check if the implementation does support the time zone name he 70 wants. the default time zone was changed to localtime again. 72 b) allow back references from :matches as well as :regex. 74 c) added a section on implementation limits. 76 d) clarified global scope so that it spans include. 78 e) clarified that this draft only affects scripts which require 79 "variables". 81 f) changed modifiers into being tagged arguments for SET, added 82 precedence table. 84 g) added optional COMPARATOR to SET to solve the internationalisation 85 problem with :lower etc. 87 h) the name of the variable being SET is passed in a string to conform 88 with overall Sieve grammar. this string is explicitly disallowed 89 from containing variable references. 91 0.2.2. Changes since -01 93 a) clarify that a character is a Unicode character. 95 b) added paragraph warning against relying on Sieve for virus checking 96 to security section. 98 c) added a paragraph defining constant string. 100 d) added namespace to grammar. 102 e) removed SETDATE. 104 f) added wording and example requiring short-circuiting of test 105 evaluation. 107 0.2.3. Changes since -02 109 a) add references to Unicode and UTF-8, also more boilerplate 111 b) fixed a meaningless example. 113 c) changed term "numeric variables" to "numbered variables" to reduce 114 the chance of it being interpreted as variables holding integer 115 values. 117 d) allow future extensions to access the raw string value. 119 e) an unsuccessful match does NOT reset the numbered variables. 121 f) added definition of "string :count" 123 g) exceeding implementation limits on variable lengths should not make 124 scripts abort. 126 0.2.4. Changes since -03 128 a) clarify short-circuiting. 130 b) editorial changes. 132 0.2.5. Changes since -04 134 a) the wildcards in :matches was changed from greedy to non-greedy to 135 better support "principle of least surprise". added example to 136 illustrate the difference. 138 b) add definition of "variable"; clarify grammar is based on [SIEVE]; 139 clarify role of namespaces; add informative references for [REGEX] 140 and [SPAMTEST]; add normative reference for [RELATIONAL] 142 c) the use of unsupported numbered variables must be flagged as a 143 syntax error by implementations. 145 0.2.6. Changes since -00 (WG series) 147 a) added example for string test 149 b) moved introductory text for MODIFIER from 5.1 into 5.0 151 c) added Syntax line for MODIFIER. 153 d) added comment to an example showing that the non-greedy "*" still 154 matches everything due to implicit anchors. 156 e) added example of expansion of string with unbalanced braces. 158 f) updated reference to [SPAMTEST]. 160 0.2.7. Changes since -01 162 a) moved References from appendix into the document itself. 164 b) added example of SET with a comparator. 166 c) changed "highest value" to the less ambiguous "largest value". 168 d) updated reference to [UTF-8]. 170 e) allow numbered variables in namespaces. 172 f) change ${0} to mean the complete match. 174 0.2.8. Changes since -02 176 a) explicitly state compatibility with actions in base spec. 178 b) "numbered variables" are now called "match variables". 180 c) clarify definition of "match variable". 182 d) it's not the whole namespace which should match the extension 183 keyword, only the first component. 185 e) allow level 2 and above of the namespace specification to be all- 186 digit. 188 f) combining :upper and :lower etc. is now a syntax error. 190 g) allow SET to set variables in namespaces if the extension allows 191 it. 193 0.2.9. Changes since -03 195 a) added two new modifiers, ":quoteregex" and ":quotewildcard". 197 b) added wording about security implications of silent truncation. 199 0.2.10. Changes since -04 201 a) fix buggy markup and add missing modifier to syntax description 203 b) changed two "syntax error" (which really weren't) into just 204 "error". 206 c) changed "Syntax:" into "Usage:" to mirror [SIEVE] convention. 208 d) removed description of regex interaction and :quoteregex 210 e) added note to clarify that ${0010} is the same as ${10}. 212 f) changed name of document to align better with other extensions 213 (uses same format at 3431 and 3894) 215 0.2.11. Changes since -05 217 a) removed "open issues" section. 219 b) updated [RELATIONAL] reference 221 0.2.12. Changes since -06 223 a) updated abstract to mention what this document extends. 225 b) changed default scoping behaviour in anticipation of "include" 226 extension. 228 c) updated reference to RFC 2234. 230 d) clarified whitespace stripping behaviour for "string" test. 232 0.2.13. Changes since -07 234 a) Replaced reference to Unicode with reference to ISO 10646 and made 235 it informational rather than normative. 237 b) Updated [ABNF] since it has been published. 239 c) Removed the use of comparator with SET to affect case folding. 240 Restrict case modifiers to US ASCII. 242 d) Mention in abstract that this draft updates RFC 3028. 244 e) Clarify that match variables contain unmodified extracts from the 245 source value. 247 f) Include "INBOX" in all mailbox names for consistency. 249 1. Introduction 251 This is an extension to the Sieve language defined by [SIEVE]. It 252 adds support for storing and referencing named data. The mechanisms 253 detailed in this document will only apply to Sieve scripts that 254 include a require clause for the "variables" extension. The require 255 clauses themselves are not affected by this extension. 257 Conventions for notations are as in [SIEVE] section 1.1, including 258 use of [KEYWORDS] and [ABNF]. The grammar builds on the grammar of 259 [SIEVE]. In this document, "character" means a character from the 260 ISO 10646 coded character set [ISO10646], which may consist of 261 multiple octets coded in [UTF-8], and "variable" is a named reference 262 to data stored or read back using the mechanisms of this extension. 264 2. Capability Identifier 266 The capability string associated with the extension defined in this 267 document is "variables". 269 3. Interpretation of strings 271 This extension changes the semantics of quoted-string, multi-line- 272 literal and multi-line-dotstuff found in [SIEVE] to enable the 273 inclusion of the value of variables. 275 When a string is evaluated, substrings matching variable-ref SHALL be 276 replaced by the value of variable-name. Only one pass through the 277 string SHALL be done. Variable names are case insensitive, so "foo" 278 and "FOO" refer to the same variable. Unknown variables are replaced 279 by the empty string. 281 variable-ref = "${" [namespace] variable-name "}" 282 namespace = identifier "." *sub-namespace 283 sub-namespace = variable-name "." 284 variable-name = num-variable / identifier 285 num-variable = 1*DIGIT 287 Examples: 288 "&%${}!" => unchanged, as the empty string is an illegal 289 identifier 290 "${doh!}" => unchanged, as "!" is illegal in identifiers 292 The variable "company" holds the value "ACME". No other variables 293 are set. 295 "${full}" => the empty string 296 "${company}" => "ACME" 297 "${BAD${Company}" => "${BADACME" 298 "${President, ${Company} Inc.}" 299 => "${President, ACME Inc.}" 301 The expanded string MUST use the variable values which are current 302 when control reaches the statement the string is part of. 304 Strings where no variable substitutions take place are referred to as 305 constant strings. Future extensions may specify that passing non- 306 constant strings as arguments to its actions or tests is an error. 308 Namespaces are meant for future extensions which make internal state 309 available through variables. These variables SHOULD be put in a 310 namespace whose first component is the same as its capability string. 311 Such extensions SHOULD state which, if any, of the variables in its 312 namespace are modifiable with the "set" action. 314 References to namespaces without a prior require statement for the 315 relevant extension MUST cause an error. 317 Tests or actions in future extensions may need to access the 318 unexpanded version of the string argument and, e.g., do the expansion 319 after setting variables in its namespace. The design of the 320 implementation should allow this. 322 3.1. Quoting 324 The semantics of quoting using backslash are not changed: backslash 325 quoting is resolved before doing variable substitution. 327 Examples: 328 "${fo\o}" => ${foo} => the expansion of variable foo. 329 "${fo\\o}" => ${fo\o} => illegal identifier => left verbatim. 330 "\${foo}" => ${foo} => the expansion of variable foo. 331 "\\${foo}" => \${foo} => a backslash character followed by the 332 expansion of variable foo. 334 If it is required to include a character sequence such as "${beep}" 335 verbatim in a text literal, the user can define a variable to 336 circumvent expansion to the empty string. 338 Example: 339 set "dollar" "$"; 340 set "text" "regarding ${dollar}{beep}"; 342 3.2. Match variables 344 A "match variable" has a name consisting only of decimal digits and 345 has no namespace component. 347 The decimal value of the match variable name will index the list of 348 matching strings from the most recently evaluated successful match of 349 type ":matches". The list is empty if no match has been successful. 351 Note: Extra leading zeroes are allowed and ignored. 353 The list will contain one string for each wildcard ("?" and "*") in 354 the match pattern. Each string holds the substring from the source 355 value that the corresponding wildcard expands to, possibly the empty 356 string. The wildcards match as little as possible (non-greedy 357 matching). 359 The first string in the list has index 1. If the index is out of 360 range, the empty string will be substituted. Index 0 contains the 361 matched part of the source value. 363 The interpreter MUST short-circuit tests, ie. not perform more tests 364 than necessary to find the result. Evaluation order MUST be left to 365 right. If a test has two or more list arguments, the implementation 366 is free to choose which to iterate over first. 368 An extension describing a new match type (e.g., [REGEX]) MAY specify 369 that match variables are set as a side effect when the match type is 370 used in a script which has enabled the "variables" extension. 372 Example: 374 require ["fileinto", "variables"]; 376 if header :matches "List-ID" "*<*@*" { 377 fileinto "INBOX.lists.${2}"; stop; 378 } 380 # Imagine the header 381 # Subject: [acme-users] [fwd] version 1.0 is out 382 if header :matches "Subject" "[*] *" { 383 # ${1} will hold "acme-users", 384 # ${2} will hold "[fwd] version 1.0 is out" 385 fileinfo "INBOX.lists.${1}"; stop; 386 } 388 # Imagine the header 389 # To: coyote@ACME.Example.COM 390 if address :matches ["To", "Cc"] ["coyote@**.com", 391 "wile@**.com"] { 392 # ${0} is the matching address 393 # ${1} is always the empty string 394 # ${2} is part of the domain name ("ACME.Example") 395 fileinto "INBOX.business.${2}"; stop; 396 } else { 397 # Control wouldn't reach this block if any match was 398 # successful, so no match variables are set at this 399 # point. 400 } 402 if anyof (true, address :domain :matches "To" "*.com") { 403 # The second test is never evaluated, so there are 404 # still no match variables set. 405 stop; 406 } 408 4. Action set 410 Usage: set [MODIFIER] 412 The "set" action stores the specified value in the variable 413 identified by name. The name MUST be a constant string and conform 414 to the syntax of variable-name. Match variables can not be set. A 415 namespace can not be used unless an extension explicitly allows its 416 use in "set". An invalid name MUST be detected as a syntax error. 418 Modifiers are applied on a value before it is stored in the variable. 419 See next section for details. 421 Variables are only visible to the currently running script. Note: 422 Future extensions may provide different scoping rules for variables. 424 Variable names are case insensitive. 426 Example: 427 set "honorific" "Mr"; 428 set "first_name" "Wile"; 429 set "last_name" "Coyote"; 430 set "vacation" text: 431 Dear ${HONORIFIC} ${last_name}, 432 I'm out, please leave a message after the meep. 433 . 434 ; 436 "set" does not affect the implicit keep. It is compatible with all 437 actions defined in [SIEVE]. 439 4.1. Modifiers 441 Usage: ":lower" / ":upper" / ":lowerfirst" / ":upperfirst" / 442 ":quotewildcard" / ":length" 444 Modifier names are case insensitive. Unknown modifiers MUST yield a 445 syntax error. More than one modifier can be specified, in which case 446 they are applied according to this precedence list, largest value 447 first: 449 +--------------------------------+ 450 | Precedence Modifier | 451 +--------------------------------+ 452 | 40 :lower | 453 | :upper | 454 +--------------------------------+ 455 | 30 :lowerfirst | 456 | :upperfirst | 457 +--------------------------------+ 458 | 20 :quotewildcard | 459 +--------------------------------+ 460 | 10 :length | 461 +--------------------------------+ 463 It is an error to use two or more modifiers of the same precedence in 464 a single "set" action. 466 Examples: 467 # The value assigned to the variable is printed after the arrow 468 set "a" "juMBlEd lETteRS"; => "juMBlEd lETteRS" 469 set :length "b" "${a}"; => "15" 470 set :lower "b" "${a}"; => "jumbled letters" 471 set :upperfirst "b" "${a}"; => "JuMBlEd lETteRS" 472 set :upperfirst :lower "b" "${a}"; => "Jumbled letters" 473 set :quotewildcard "b" "Rock*"; => "Rock\*" 475 4.1.1. Modifier ":length" 477 The value is the decimal number of characters in the expansion, 478 converted to a string. 480 4.1.2. Modifier ":quotewildcard" 482 This modifier adds the necessary quoting to ensure that the expanded 483 text will only match a literal occurence if used as a parameter to 484 :matches. Every character with special meaning ("*", "?" and "\") 485 is prefixed with "\" in the expansion. 487 4.1.3. Case modifiers 489 These modifiers change the letters of the text from upper to lower 490 case or vice versa. Characters other than "A"-"Z", "a"-"z" from US- 491 ASCII are left unchanged. 493 4.1.3.1. Modifier ":upper" 495 All lower case letters are converted to their upper case counterpart. 497 4.1.3.2. Modifier ":lower" 499 All upper case letters are converted to their lower case counterpart. 501 4.1.3.3. Modifier ":upperfirst" 503 The first character of the string is converted to upper case if it is 504 a letter and set in lower case. The rest of the string is left 505 unchanged. 507 4.1.3.4. Modifier ":lowerfirst" 509 The first character of the string is converted to lower case if it is 510 a letter and set in upper case. The rest of the string is left 511 unchanged. 513 5. Test string 515 Usage: string [MATCH-TYPE] [COMPARATOR] 516 518 The "string" test evaluates to true if any of the source strings 519 matches any key. The type of match defaults to ":is". 521 In the "string" test, both source and key-list are taken from the 522 script, not the message, and whitespace stripping MUST NOT be done 523 unless the script explicitly requests this through some future 524 mechanism. 526 Example: 527 set "state" "${state} pending"; 528 if string :matches " ${state} " "* pending *" { 529 # the above test always succeeds 530 } 532 The "relational" extension [RELATIONAL] adds a match type called 533 ":count". The count of a single string is 0 if it is the empty 534 string, or 1 otherwise. The count of a string list is the sum of the 535 counts of the member strings. 537 6. Implementation Limits 539 An implementation of this draft MUST support at least 128 distinct 540 variables. The supported length of variable names MUST be at least 541 32 characters. Each variable MUST be able to hold at least 4000 542 characters. Attempts to set the variable to a value larger than what 543 the implementation supports SHOULD be reported as an error at 544 compile-time if possible. If the attempt is discovered during run- 545 time, the value SHOULD be truncated and it MUST NOT be treated as an 546 error. 548 Match variables ${1} through ${9} MUST be supported. References to 549 higher indices than the implementation supports MUST be treated as a 550 syntax error which SHOULD be discovered at compile-time. 552 7. Security Considerations 554 When match variables are used, and the author of the script isn't 555 careful, strings can contain arbitrary values controlled by the 556 sender of the mail. 558 Since values stored by "set" which exceed implementation limits are 559 silently truncated, it's not appropriate to store large structures 560 with security implications in variables. 562 The introduction of variables makes advanced decision making easier 563 to write, but since no looping construct is provided, all Sieve 564 scripts will terminate in an orderly manner. 566 Sieve filtering should not be relied on as a security measure against 567 hostile mail messages. Sieve is designed to do simple, mostly static 568 tests, and is not suitable for use as a spam or virus checker, where 569 the perpetrator has a motivation to vary the format of the mail in 570 order to avoid filtering rules. See also [SPAMTEST]. 572 8. IANA Considerations 574 The following template specifies the IANA registration of the 575 variables Sieve extension specified in this document: 577 To: iana@iana.org 578 Subject: Registration of new Sieve extension 580 Capability name: variables 581 Capability keyword: variables 582 Capability arguments: N/A 583 Standards Track/IESG-approved experimental RFC number: 584 this RFC 585 Person and email address to contact for further information: 586 Kjetil Torgrim Homme 587 kjetilho@ifi.uio.no 589 This information should be added to the list of sieve extensions 590 given on http://www.iana.org/assignments/sieve-extensions. 592 9. Acknowledgments 594 Thanks to Cyrus Daboo, Jutta Degener, Ned Freed, Lawrence Greenfield, 595 Jeffrey Hutzelman, Mark E. Mallett, Alexey Melnikov, Peder Stray and 596 Nigel Swinson for valuable feedback. 598 10. Author's Address 600 Kjetil T. Homme 601 University of Oslo 602 PO Box 1080 603 0316 Oslo, Norway 605 Phone: +47 9366 0091 606 E-mail: kjetilho@ifi.uio.no 608 11. References 610 11.1. Normative references 612 [ABNF] Crocker, D. and Overell, P., "Augmented BNF for Syntax 613 Specifications: ABNF", RFC 4234, October 2005. 615 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", RFC 2119, March 1997. 618 [RELATIONAL] Leiba, B. and Segmuller, W., "Sieve Extension: 619 Relational Tests", Work in Progress, draft-ietf- 620 sieve-3431bis-XX.txt 622 [SIEVE] Guenther, P. and Showalter, T., "Sieve: An Email 623 Filtering Language", Work in Progress, draft-ietf- 624 sieve-3028bis-XX.txt 626 [UTF-8] Yergeau, F., "UTF-8, a transformation format of 627 Unicode and ISO 10646", RFC 3629, November 2003. 629 11.2. Informative References 631 [ISO10646] ISO/IEC, "Information Technology - Universal Multiple- 632 Octet Coded Character Set (UCS) - Part 1: Architecture 633 and Basic Multilingual Plane", May 1993, with 634 amendments. 636 [REGEX] Murchison, K., "Sieve Email Filtering -- Regular 637 Expression Extension", Work in Progress. 639 [SPAMTEST] Daboo, C., "SIEVE Email Filtering: Spamtest and 640 VirusTest Extensions", RFC 3685, February 2004 642 Appendix B. Intellectual Property Rights Statement 644 The IETF takes no position regarding the validity or scope of any 645 intellectual property or other rights that might be claimed to 646 pertain to the implementation or use of the technology described in 647 this document or the extent to which any license under such rights 648 might or might not be available; neither does it represent that it 649 has made any effort to identify any such rights. Information on the 650 IETF's procedures with respect to rights in standards-track and 651 standards-related documentation can be found in BCP-11. Copies of 652 claims of rights made available for publication and any assurances of 653 licenses to be made available, or the result of an attempt made to 654 obtain a general license or permission for the use of such 655 proprietary rights by implementors or users of this specification can 656 be obtained from the IETF Secretariat. 658 Appendix C. Full Copyright Statement 660 Copyright (C) The Internet Society (2005). 662 This document is subject to the rights, licenses and restrictions 663 contained in BCP 78, and except as set forth therein, the authors 664 retain all their rights. 666 This document and the information contained herein are provided on an 667 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 668 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 669 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 670 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 671 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 672 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 674 Intellectual Property 676 The IETF takes no position regarding the validity or scope of any 677 Intellectual Property Rights or other rights that might be claimed to 678 pertain to the implementation or use of the technology described in 679 this document or the extent to which any license under such rights 680 might or might not be available; nor does it represent that it has 681 made any independent effort to identify any such rights. Information 682 on the procedures with respect to rights in RFC documents can be 683 found in BCP 78 and BCP 79. 685 Copies of IPR disclosures made to the IETF Secretariat and any 686 assurances of licenses to be made available, or the result of an 687 attempt made to obtain a general license or permission for the use of 688 such proprietary rights by implementers or users of this 689 specification can be obtained from the IETF on-line IPR repository at 690 http://www.ietf.org/ipr. 692 The IETF invites any interested party to bring to its attention any 693 copyrights, patents or patent applications, or other proprietary 694 rights that may cover technology that may be required to implement 695 this standard. Please address the information to the IETF at ietf- 696 ipr@ietf.org. 698 Acknowledgement 700 Funding for the RFC Editor function is currently provided by the 701 Internet Society.