idnits 2.17.1 draft-ietf-sieve-notify-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2007) is 6288 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 461, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba, Ed. 5 Expires: August 4, 2007 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 January 31, 2007 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-06 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 4, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 Users go to great lengths to be notified as quickly as possible that 46 they have received new mail. Most of these methods involve polling 47 to check for new messages periodically. A push method handled by the 48 final delivery agent gives users quicker notifications and saves 49 server resources. This document does not specify the notification 50 method but it is expected that using existing instant messaging 51 infrastructure such as XMPP, or SMS messages will be popular. This 52 draft describes an extension to the Sieve mail filtering language 53 that allows users to give specific rules for how and when 54 notifications should be sent. 56 Changes since draft-ietf-sieve-notify-05 58 o Fixed XMPP URI in one example. 60 o Addressed Michael's issue with how timestamp are described. 62 o Renamed "valid_notif_method" to "valid_notify_method". 64 o Added text about truncation of a textual part when it is stored in 65 a variable using extract_text. 67 o Changed tagged :method argument to positional argument. 69 o Added text about notification throttling, identifying notification 70 source and restricting values of the :from parameter. 72 o Added a requirement on documents describing notification methods 73 to list which URI parameters must be ignored. 75 Changes since draft-ietf-sieve-notify-04 77 o Made notification method required. 79 o Defined "mailto" as a mandatory-to-implement method. 81 o Added normative reference to mailto. 83 o Clarified that :importance may be treated as a transport 84 indicator. 86 o Clarified that :importance value can be included in the default 87 :message, if one is not specified. 89 o Made the default :message implementation specific. 91 o Renamed the capability name from "notify" to "enotify" 93 o Updated IANA registration. 95 o Moved text about ManageSieve capability to the ManageSieve 96 document itself. 98 o Removed reference to IANA registry for options. 100 o Some miscellaneous text cleanup and clarification. 102 Changes since draft-ietf-sieve-notify-03 104 o Added a warning that "notify" must not be used as a crappy form of 105 "redirect". 107 o Added a warning about using "notify" to forward confidential 108 information in order to bypass organization's policy. 110 o Fixed syntax of the :options argument - it is a string list, each 111 string containing "=" 113 o Renamed :priority to :importance 115 o Cleaned up section about requirements on methods. 117 Changes since draft-ietf-sieve-notify-02 119 o Added :from tagged argument. 121 o Added Extract_text action, which allows to extract content of the 122 first text/* part. 124 o Added back the ":options" parameter to the notify action. 126 o Added new section talking about requirements on notification 127 method specs. 129 o Added more examples. 131 Changes since draft-ietf-sieve-notify-00 133 o Updated references, etc. 135 o Added IANA considerations section. 137 o Removed denotify action. 139 o Updated examples to use the variables extension. 141 o Replaced notification method with URI. 143 o Removed text suggesting that this extension can be used to track 144 all Sieve actions taken. 146 o Changed priority to be a string. 148 o Added text about URI verification. 150 o Clarified that a notification method is allowed to perform 151 adaptation of notification context (e.g. truncation, charset 152 conversion, etc.). These adaptations must be documented in a 153 document describing the notification method. 155 o Clarified that notify is compatible with all existing actions. 157 o Removed the :id parameter to the notify action. 159 o Added valid_notif_method test that allows to test if an 160 notification method (URI) is supported. 162 o Added a new capability response to ManageSieve that allows to 163 report supported notification types. 165 Table of Contents 167 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 168 1.1. Conventions used in this document . . . . . . . . . . . . . 6 170 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 6 172 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 6 173 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 6 174 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 6 175 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 7 176 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 7 177 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 8 178 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 8 179 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 180 3.8. Requirements on notification methods specifications . . . . 11 182 4. Extract_text Action . . . . . . . . . . . . . . . . . . . . 12 184 5. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13 186 6. Interactions with Other Sieve Actions . . . . . . . . . . . 14 188 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 190 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 192 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 194 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 195 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 15 196 10.2. Informative References . . . . . . . . . . . . . . . . . . . 16 198 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 199 Intellectual Property and Copyright Statements . . . . . . . 18 201 1. Introduction 203 This is an extension to the Sieve language defined by [Sieve] for 204 providing instant notifications. It defines the new action "notify". 206 This document does not specify the notification methods. Examples of 207 possible notification methods are email and XMPP. To allow a 208 mechanism for portability of scripts that use notifications, 209 implementation of the [MailTo] method is mandatory. Other available 210 methods shall depend upon the implementation and configuration of the 211 system. 213 1.1. Conventions used in this document 215 Conventions for notations are as in [Sieve] section 1.1, including 216 the use of [ABNF]. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [Kwds]. 222 2. Capability Identifier 224 The capability string associated with the extension defined in this 225 document is "enotify". 227 3. Notify Action 229 3.1. Notify Action Syntax and Semantics 231 Usage: notify [":from" string] 232 [":importance" <"1" / "2" / "3">] 233 [":options" string-list] 234 [":message" string] 235 237 The Notify action specifies that a notification should be sent to a 238 user. The format of the notification is implementation-defined and 239 is also affected by the notification method used (see Section 3.2). 240 However, all content specified in the :message parameter SHOULD be 241 included. 243 3.2. Notify parameter "method" 245 The method positional parameter identifies the notification method 246 that will be used; it is a URI [URI]. For example, the notification 247 method can be an SMS URI [SMS-URI] containing a phone number, or an 248 XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]. 250 The supported URI values will be site-specific, but support for the 251 [MailTo] method is REQUIRED in order to insure interoperability. If 252 a URI schema is specified that the implementation does not support, 253 the notification MUST cause an error condition. Sieve scripts can 254 check the supported methods using the "valid_notify_method" test to 255 be sure that they only use supported ones, to avoid such error 256 conditions. 258 If the method parameter contains a supported URI schema, then the URI 259 MUST be checked for syntactic validity. An invalid URI syntax or an 260 unsupported URI extension MUST cause an error. An implementation MAY 261 enforce other semantic restrictions on URIs -- for example an SMS URI 262 can only contain phone numbers in a particular geographical region -- 263 and will treat violations of such semantic restrictions as errors. 265 3.3. Notify tag ":from" 267 A ":from" parameter may be used to specify an author of the 268 notification. The syntax of this parameter's value is method- 269 specific. Implementations SHOULD check the syntax according to the 270 notification method specification and generate an error when a 271 syntactically invalid ":from" parameter is specified. In order to 272 minimize/prevent forgery of the author value, implementations SHOULD 273 impose restrictions on what values can specified in a ":from" 274 parameter; it is suggested that values which fail such a validity 275 check simply be ignored rather than causing the notify action to 276 fail. 278 3.4. Notify tag ":importance" 280 The :importance tag specifies the importance of the delivery of the 281 notification. The :importance tag is followed by a numeric value 282 represented as a string: "1" (high importance), "2" (normal 283 importance), and "3" (low importance). If no importance is given, 284 the default value "2" SHOULD be assumed. A notification method can 285 treat the importance value as a transport indicator. For example, it 286 might deliver notifications of high importance quicker than 287 notifications of normal or low importance. Some notification methods 288 allow users to specify their state of activity (for example "busy" or 289 "away from keyboard"). If the notification method provides this 290 information it SHOULD be used to selectively send notifications. If, 291 for example, the user marks herself as "busy", a notification method 292 can require that a notification with importance of "3" is not to be 293 sent, however the user should be notified of a notification with 294 higher importance. 296 If the notification method allows users to filter messages based upon 297 certain parameters in the message, users SHOULD be able to filter 298 based upon importance. If the notification method does not support 299 importance, then this parameter MUST be ignored, however an 300 implementation MAY include the importance value in the default 301 message Section 3.6, if one is not provided. 303 3.5. Notify tag ":options" 305 The :options tag is used to send additional parameters to the 306 notification method. Interpretation of the parameters is method- 307 specific. This document doesn't specify any such additional 308 parameter. 310 Each string in the options string list has the following syntax: 311 "=" [[Alexey 3: Should we say something about 312 implementation prefix for implementation specific options? Something 313 like "x-Vendor-zzz". If we don't say it now, it might be too late to 314 say it later.]] 316 3.6. Notify tag ":message" 318 The :message tag specifies the message data to be included in the 319 notification. The entirety of the string SHOULD be sent but 320 implementations MAY shorten the message for technical or aesthetic 321 reasons. If the message parameter is absent, a default 322 implementation-specific message is used. Unless specified otherwise 323 by a particular notification mechanism, an implementation default 324 containing at least the value of the "From" header field and the 325 value of the "Subject" header field is RECOMMENDED. 327 In order to construct more complex messages the notify extension can 328 be used together with the Sieve variables extension [Variables], as 329 shown in the examples below. 331 3.7. Examples 332 Example 1: 333 require ["enotify", "fileinto", "variables"]; 335 if header :contains "from" "boss@example.org" { 336 notify :importance "1" 337 :message "This is probably very important" 338 "mailto:alm@example.com"; 339 # Don't send any further notifications 340 stop; 341 } 343 if header :contains "to" "sievemailinglist@example.org" { 344 # :matches is used to get the value of the Subject header 345 if header :matches "Subject" "*" { 346 set "subject" "${1}"; 347 } 349 # :matches is used to get the value of the From header 350 if header :matches "From" "*" { 351 set "from" "${1}"; 352 } 354 notify :importance "3" 355 :message "[SIEVE] ${from}: ${subject}" 356 "mailto:alm@example.com"; 357 fileinto "INBOX.sieve"; 358 } 360 Example 2: 361 require ["enotify", "fileinto", "variables", "envelope"]; 363 if header :matches "from" "*@*.example.org" { 364 # :matches is used to get the MAIL FROM address 365 if envelope :all :matches "from" "*" { 366 set "env_from" " [really: ${1}]"; 367 } 369 # :matches is used to get the value of the Subject header 370 if header :matches "Subject" "*" { 371 set "subject" "${1}"; 372 } 374 # :matches is used to get the address from the From header 375 if address :matches :all "from" "*" { 376 set "from_addr" "${1}"; 377 } 379 notify :message "${from_addr}${env_from}: ${subject}" 380 "mailto:alm@example.com"; 381 } 383 Example 3: 384 require ["enotify", "variables"]; 386 set "notif_method" 387 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; 389 if header :contains "subject" "Your dog" { 390 set "notif_method" "sms:+14085551212"; 391 } 393 if header :contains "to" "sievemailinglist@example.org" { 394 set "notif_method" ""; 395 } 397 if not string :is "${notif_method}" "" { 398 notify "${notif_method}"; 399 } 401 if header :contains "from" "boss@example.org" { 402 # :matches is used to get the value of the Subject header 403 if header :matches "Subject" "*" { 404 set "subject" "${1}"; 405 } 407 # don't need high importance notification for 408 # a 'for your information' 409 if not header :contains "subject" "FYI:" { 410 notify :importance "1" :message "BOSS: ${subject}" 411 "sms:+14085551212"; 412 } 413 } 415 3.8. Requirements on notification methods specifications 417 This section describes requirements for documents that define 418 specific Sieve notification methods. 420 A notification method MAY allow modification of the final 421 notification text -- for example, truncating it if it exceeds a 422 length limit, or modifying characters that can not be represented in 423 the target character set. Characters in the notification text which 424 can't be represented by the notification method SHOULD be replaced 425 with a symbol indicating an unknown character. Allowed modifications 426 MUST be documented in the document describing the notification 427 method. 429 A notification method MAY ignore parameters specified in the Notify 430 action. 432 A notification method MAY recommend the default message value to be 433 used if the :message argument is not specified. 435 Notifications SHOULD include timestamps, if the notification method 436 allows for their transmission outside of the textual message. 437 Implementation methods which can only transmit timestamps in the 438 textual message MAY include them in the textual message. 440 Notifications SHOULD includes means to identify/track its origin, in 441 order to allow a recipient to stop notifications or find out how to 442 contact the sender. This requirement is to help tracking a 443 misconfigured or abusive origin of notifications. 445 Methods SHOULD NOT include any other extraneous information not 446 specified in parameters to the notify action. 448 Methods MUST specify which URI parameters (if any) must be ignored 449 and which ones must be used in the resulting notification. 451 If there are errors sending the notification, the Sieve interpreter 452 SHOULD ignore the notification and not retry indefinitely. The Sieve 453 interpreter MAY throttle notifications; if it does, a request to send 454 a notification can be silently ignored. Documents describing 455 notification methods SHOULD describe how retries, throttling, 456 duplicate suppression (if any), etc. are to be handled by 457 implementations. 459 4. Extract_text Action 461 Usage: extract_text [MODIFIER] [":first" number] 462 464 The Extract_text action stores at most :first bytes of the first 465 text/* part in the variable identified by varname. If the :first 466 parameter is not present, the whole content of the first text/* part 467 is stored. In either case the actually stored data MAY be truncated 468 to conform to implementation specific limit on variable length and/or 469 on MIME body part length. 471 If the message being processed doesn't contain any text/* part, the 472 action will set the variable identified by varname to the empty 473 string. [[Alexey 5: Do we need to be more specific about what "the 474 first text part" means?]] 476 Modifiers are applied on the extracted text before it is stored in 477 the variable. See [Variables] for details. 479 Note that this action is only available when the Sieve script 480 specifies both "variables" [Variables] and "enotify" capabilities in 481 the require statements. 483 Example 4: 484 require ["enotify", "variables"]; 486 if header :contains "from" "boss@example.org" { 487 # :matches is used to get the value of the Subject header 488 if header :matches "Subject" "*" { 489 set "subject" "${1}"; 490 } 492 # extract the first 100 bytes of the first text/* part 493 extract_text :first 100 "msgcontent"; 495 # don't need high importance notification for 496 # a 'for your information' 497 if not header :contains "subject" "FYI:" { 498 notify :importance "1" 499 :message "BOSS: ${subject}; ${msgcontent}" 500 "sms:+14085551212"; 501 } 502 } 504 5. Test valid_notify_method 506 Usage: valid_notify_method 508 The "valid_notify_method" test is true if the notification methods 509 listed in the notification-uris argument are supported and they are 510 syntactically and semantically (including implementation-specific 511 semantic restrictions) valid. This test MUST perform exactly the 512 same validation as would be performed on the "method" parameter to 513 the "notify" action. 515 The test is true only if ALL of the listed notification methods are 516 supported and valid. 518 Example 5: 519 if not valid_notify_method ["mailto:", 520 "http://gw.example.net/notify?test"] { 522 stop; 523 } 525 6. Interactions with Other Sieve Actions 527 The notify action is compatible with all other actions, and does not 528 affect the operation of other actions. In particular, the notify 529 action MUST NOT cancel the implicit keep. 531 Multiple executed notify actions are allowed. Specific notification 532 methods MAY allow multiple notifications from the same script to be 533 collapsed into one. 535 7. Security Considerations 537 Security considerations are discussed in [Sieve]. Additionally, 538 implementations must be careful to follow the security considerations 539 of the specific notification methods. 541 The notify action is potentially very dangerous. The path the 542 notification takes through the network may not be secure. An error 543 in the options string may cause the message to be transmitted to 544 someone it was not intended for, or may expose information to 545 eavesdroppers. 547 Just because a notification is received doesn't mean that it was sent 548 by the Sieve implementation. It might be possible to forge 549 notifications with some notification methods. 551 An organization may have a policy about the forwarding of classified 552 information to unclassified networks. Unless the policy is also 553 enforced in the module responsible for generating (or sending) of 554 notifications, users can use the extension defined in this document 555 to extract classified information and bypass the policy. 557 Notifications can result in loops and bounces. [[Michael suggested 558 to delete this example: In particular, a notification to an email 559 address will not contain necessary Received header fields that might 560 be otherwise used to prevent mail loops.]] All notification methods 561 must take care to provide mechanisms for avoiding notification loops. 563 8. IANA Considerations 565 The following template specifies the IANA registration of the notify 566 Sieve extension specified in this document: 568 To: iana@iana.org 569 Subject: Registration of new Sieve extension 570 Capability name: enotify 571 Description: adds the 'notify' action for notifying user about the 572 received message; also adds the 'extract_text' action for extracting 573 a part of the first textual bodypart. 574 RFC number: this RFC 575 Contact address: 576 The Sieve discussion list 578 This information should be added to the list of sieve extensions 579 given on http://www.iana.org/assignments/sieve-extensions. 581 9. Acknowledgements 583 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 584 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 585 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov and Peter Saint- 586 Andre for help with this document. 588 10. References 590 10.1. Normative References 592 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 593 Specifications: ABNF", RFC 4234, October 2005. 595 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", RFC 2119, March 1997. 598 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 599 mailto", work in progress, draft-ietf-sieve-notify-mailto, 600 October 2006. 602 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 603 Language", work in progress, draft-ietf-sieve-3028bis, 604 August 2006. 606 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 607 Resource Identifier (URI): Generic Syntax", STD 66, 608 RFC 3986, January 2005. 610 [Variables] 611 Homme, K., "Sieve Extension: Variables", work in 612 progress, draft-ietf-sieve-variables, December 2005. 614 10.2. Informative References 616 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 617 Message Service", work in progress, draft-wilde-sms-uri, 618 August 2005. 620 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 621 Protocol (XMPP): Core", RFC 3920, October 2004. 623 [XMPP-URI] 624 Saint-Andre, P., "Internationalized Resource Identifiers 625 (IRIs) and Uniform Resource Identifiers (URIs) for the 626 Extensible Messaging and Presence Protocol (XMPP)", work 627 in progress, draft-saintandre-xmpp-iri, September 2005. 629 Authors' Addresses 631 Alexey Melnikov (editor) 632 Isode Limited 633 5 Castle Business Village 634 36 Station Road 635 Hampton, Middlesex TW12 2BX 636 UK 638 Email: Alexey.Melnikov@isode.com 640 Barry Leiba (editor) 641 IBM T.J. Watson Research Center 642 19 Skyline Drive 643 Hawthorne, NY 10532 644 US 646 Phone: +1 914 784 7941 647 Email: leiba@watson.ibm.com 649 Wolfgang Segmuller 650 IBM T.J. Watson Research Center 651 19 Skyline Drive 652 Hawthorne, NY 10532 653 US 655 Phone: +1 914 784 7408 656 Email: werewolf@us.ibm.com 657 Tim Martin 658 BeThereBeSquare Inc. 659 672 Haight st. 660 San Francisco, CA 94117 661 US 663 Phone: +1 510 260-4175 664 Email: timmartin@alumni.cmu.edu 666 Full Copyright Statement 668 Copyright (C) The IETF Trust (2007). 670 This document is subject to the rights, licenses and restrictions 671 contained in BCP 78, and except as set forth therein, the authors 672 retain all their rights. 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 677 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 678 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Acknowledgment 708 Funding for the RFC Editor function is provided by the IETF 709 Administrative Support Activity (IASA).