idnits 2.17.1 draft-ietf-sieve-vacation-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (September 21, 2005) is 6791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3461' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sieve-refuse-reject' is defined on line 518, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-sieve-variables-04 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIEVE Email Filtering Working T. Showalter 3 Group ?? 4 Internet-Draft N. Freed, Ed. 5 Expires: March 25, 2006 Sun Microsystems 6 September 21, 2005 8 Sieve Email Filtering: Vacation Extension 9 draft-ietf-sieve-vacation-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with 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 This Internet-Draft will expire on March 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes an extension to the Sieve email filtering 43 language for an autoresponder similar to that of the Unix "vacation" 44 command for replying to messages. Various safety features are 45 included to prevent problems such as message loops. 47 Change History (to be removed prior to publication as an RFC) 48 Changes from draft-showalter-sieve-vacation-06.txt: 50 1. Updated to XML source. 52 2. Added :from parameter. 54 3. Added :handle parameter. 56 4. Added more detailed description of :subject parameter 58 5. Clarified some discussion text. 60 6. Fixed various minor typos. 62 7. Refinement of duplicate response suppression semantics 64 8. Added a statement that vacation is incompatible with reject 66 9. Prohibited the use of 8bit material in MIME headers specified 67 when :mime is in effect. 69 10. Use "Auto:" instead of "Re:" in automatically generated subject 70 lines 72 11. Added an explicit list of registered "List-*" header fields to 73 check for 75 12. Switched Syntax: label to Usage: 77 13. Updated draft to refer to RFC 3028bis instead of RFC 3028. 79 14. Removed reference to section 2.4.2.4 of RFC 3028 since the 80 section no longer exists in the revised version. 82 15. Updated reference for sieve reject, added text about refuse. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 2. Conventions used in this document . . . . . . . . . . . . . . 4 88 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 89 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 90 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 91 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 92 4.3. Subject and from parameters . . . . . . . . . . . . . . . 7 93 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 94 4.5. Address Parameter and Limiting Replies to Personal 95 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 96 4.6. Restricting Replies to Automated Processes and Mailing 97 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 98 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8 99 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 5. Response Message Generation . . . . . . . . . . . . . . . . . 9 101 5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 9 102 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 103 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 104 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 105 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 106 5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 10 107 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10 108 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10 109 6. Relationship to Recommendations for Automatic Responses to 110 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 10 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 116 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 118 Intellectual Property and Copyright Statements . . . . . . . . . . 15 120 1. Introduction 122 This document defines an extension to the Sieve language defined in 123 [I-D.ietf-sieve-3028bis] for notification that messages to a 124 particular recipient will not be answered immediately. 126 2. Conventions used in this document 128 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 129 1.1. 131 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and 132 "MAY" in this document are to be interpreted as defined in [RFC2119]. 134 3. Capability Identifier 136 Sieve implementations that implement vacation have an identifier of 137 "vacation" for use with the capability mechanism. 139 4. Vacation Action 141 Usage: vacation [":days" number] [":subject" string] 142 [":from" string] [":addresses" string-list] 143 [":mime"] [":handle" string] 145 The "vacation" action implements a vacation autoresponder similar to 146 the vacation command available under many versions of Unix. Its 147 purpose is to provide correspondents with notification that the user 148 is away for an extended period of time and that they should not 149 expect quick responses. 151 "Vacation" is used to respond to a message with another message. 152 Vacation's messages are always addressed to the Return-Path address 153 (that is, the envelope from address) of the message being responded 154 to. 156 4.1. Days Parameter 158 The ":days" argument is used to specify the period in which addresses 159 are kept and are not responded to, and is always specified in days. 160 The minimum value used for this parameter is normally 1. Sites MAY 161 define a different minimum value as long as the minimum is greater 162 than 0. Sites MAY also define a maximum days value, which MUST be 163 greater than 7, and SHOULD be greater than 30. 165 If ":days" is omitted, the default value is either 7 or the minimum 166 value (as defined above), whichever is greater. 168 If the parameter given to ":days" is less than the minimum value, 169 then the minimum value is used instead. 171 If ":days" exceeds the site-defined maximum, the site-defined maximum 172 is used instead. 174 4.2. Previous Response Tracking 176 "Vacation" keeps track of all of the responses it has sent to each 177 address in some period (as specified by the :days optional argument). 178 If vacation has not previously sent the response to this address 179 within the given time period, it sends the "reason" argument to the 180 SMTP MAIL FROM address of the message that is being responded to. 181 (The SMTP MAIL FROM address should be available in the Return-path: 182 header field if Sieve processing occurs after final delivery.) 184 Tracking is not just per address, but must also take the vacation 185 response itself into account. A script writer might, for example, 186 have a vacation action that will send a general notice only once in 187 any two-week period. However, even if a sender has received this 188 general notice, it may be important to send a specific notice when a 189 message about something timely or something specific has been 190 detected. 192 A particular vacation response can be identified in one of two ways. 193 The first way is via an explicit :handle argument, which attaches a 194 name to the response. All vacation statements that use the same 195 handle will be considered to be the same response for tracking 196 purposes. 198 The second way is via a synthesis of the :subject, :from, :mime, and 199 reason vacation command arguments. All vacation actions that do not 200 contain an explicit handle and which use an identical combination of 201 these arguments are considered to be the same for tracking purposes. 203 For instance, If coyote@desert.example.org sends mail to 204 roadrunner@acme.example.com twice, once with the subject "Cyrus bug" 205 and once with the subject "come over for dinner", and 206 roadrunner@acme.example.com has the script shown below, 207 coyote@desert.example.org would receive two responses, once with the 208 first message, once with the second. 210 require "vacation"; 211 if header :contains "subject" "cyrus" { 212 vacation "I'm out -- send mail to cyrus-bugs"; 213 } else { 214 vacation "I'm out -- call me at 304 555 1212"; 215 } 217 In the above example, coyote@desert.example.org gets the second 218 message despite having gotten the first one because separate vacation 219 responses have been triggered. This behavior is REQUIRED. 221 There is one important exception to this rule, however. If the sieve 222 variables extension [I-D.ietf-sieve-variables] is used, the arguments 223 MUST NOT have undergone variable expansion prior to their use in 224 response tracking. This is so that examples like the following 225 script will only generate a single response to each incoming message 226 with a different subject line. 228 require ["vacation", "variables"]; 229 if header :matches "subject" "*" { 230 vacation :subject "Automatic response to: ${1}" 231 "I'm away -- send mail to foo in my absence"; 232 } 234 As noted above, the optional ":handle" parameter can be used to tell 235 the Sieve interpreter to treat two vacation actions with different 236 arguments as the same command for purposes of response tracking. The 237 argument to ":handle" is a string that identifies the type of 238 response being sent. For instance, if tweety@cage.example.org sends 239 mail to spike@doghouse.example.com twice, one with the subject 240 "lunch?" and once with the subject "dinner?", and 241 spike@doghouse.example.com has the script shown below, 242 tweety@cage.example.org will only receive a single response. (Which 243 response is sent depends on the order in which the messages are 244 processed.) 246 require "vacation"; 247 if header :contains "subject" "lunch" { 248 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 249 } else { 250 vacation :handle "ran-away" "I'm out"; 251 } 253 NOTE: One way to implement the necessary mechanism here is to store a 254 hash of either the current handle and the recipient address or, if no 255 handle is provided, a hash of the vacation action parameters 256 specifying the message content and the recipient address. If a 257 script is changed, implementations MAY reset the records of who has 258 been responded to and when they have been responded to. 260 Implementations are free to limit the number of remembered responses, 261 provided the limit is no less than 1000. When limiting the number of 262 tracked responses, implementations SHOULD discard the oldest ones 263 first. 265 4.3. Subject and from parameters 267 The ":subject" parameter specifies a subject line to attach to any 268 vacation response that is generated. UTF-8 characters can be used in 269 the string argument; implementations MUST convert the string to 270 [RFC2047] encoded words if and only if non-ASCII characters are 271 present. Implementations MUST generate an appropriate default 272 subject line as specified below if no :subject parameter is 273 specified. 275 A ":from" parameter may be used to specify an alternate address to 276 use in the From field of vacation messages. The string must specify 277 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 278 syntax and generate an error when a syntactically invalid ":from" 279 parameter is specified. Implementations MAY also impose restrictions 280 on what addresses can specified in a ":from" parameter; it is 281 suggested that values which fail such a security check simply be 282 ignored rather than causing the vacation action to fail. 284 4.4. MIME Parameter 286 The ":mime" parameter, if supplied, specifies that the reason string 287 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 288 including both MIME headers and content. 290 If the optional :mime parameter is not supplied, the reason string is 291 considered to be a UTF-8 string. 293 4.5. Address Parameter and Limiting Replies to Personal Messages 295 "Vacation" MUST NOT respond to a message unless the recipient user's 296 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 297 "Resent-Bcc" line of the original message. An email address is 298 considered to belong to the recipient if it is one of: 300 1. An email address known by the implementation to be associated 301 with the recipient, 303 2. the final envelope recipient address if it's available to the 304 implementation, or 306 3. an address specified by the script writer via the ":addresses" 307 argument described in the next paragraph. 309 Users can supply additional mail addresses that are theirs with the 310 ":addresses" argument, which takes a string-list listing additional 311 addresses that a user might have. These addresses are considered to 312 belong to the recipient user in addition to the addresses known to 313 the implementation. 315 4.6. Restricting Replies to Automated Processes and Mailing Lists 317 Implementations MUST have a list of addresses that "vacation" MUST 318 NOT send mail to. However, the contents of this list are 319 implementation defined. The purpose of this list is to stop mail 320 from going to addresses used by system daemons that would not care if 321 the user is actually reading her mail. 323 Implementations are encouraged, however, to include well-known 324 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 325 addresses typically used only by automated systems. Additionally, 326 addresses ending in "-request" or beginning in "owner-", i.e., 327 reserved for mailing list software, are also suggested. 329 Implementors may take guidance from [RFC2142], but should be careful. 330 Some addresses, like "POSTMASTER", are generally actually managed by 331 people, and people do care if the user is going to be unavailable. 333 Implementations SHOULD NOT respond to any message that contains a 334 "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- 335 Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] 336 header field. 338 Implementations SHOULD NOT respond to any message that has an "Auto- 339 submitted" header field with a value other than "no". This header 340 field is described in [RFC3834]. 342 4.7. Interaction with Other Sieve Actions 344 Vacation does not affect Sieve's implicit keep action. 346 Vacation can only be executed once per script. A script will fail if 347 it attempts to execute two or more vacation actions. 349 Implementations MUST NOT consider vacation used with discard, keep, 350 fileinto, or redirect an error. The vacation action is incompatible 351 with the sieve reject and refuse actions [I-D.ietf-sieve-refuse- 352 reject]. 354 4.8. Examples 356 Here is a simple use of vacation. 358 require "vacation"; 359 vacation :days 23 :addresses ["tjs@example.edu", 360 "ts4z@landru.example.edu"] 361 "I'm away until October 19. 362 If it's an emergency, call 911, I guess." ; 364 By mingling vacation with other rules, users can do something more 365 selective. 367 require "vacation"; 368 if header :contains "from" "boss@example.edu" { 369 redirect "pleeb@isp.example.org"; 370 } else { 371 vacation "Sorry, I'm away, I'll read your 372 message when I get around to it."; 373 } 375 5. Response Message Generation 377 This section details the requirements for the generated response 378 message. 380 It is worth noting that the input message and arguments may be in 381 UTF-8, and that implementations MUST deal with UTF-8 input, although 382 implementations MAY transcode to other character sets as regional 383 taste dictates. When :mime is used the reason argument also contains 384 MIME header information. The headers must conform to MIME 385 conventions; in particular, 8bit text is not allowed. 386 Implementations SHOULD reject vacation :mime actions containing 8bit 387 header material. 389 5.1. SMTP MAIL FROM address 391 The SMTP MAIL FROM address of the message envelope SHOULD be set to 392 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 393 SMTP transaction if the NOTARY SMTP extension [RFC3461]is available. 395 5.2. Date 397 The Date field SHOULD be set to the date and time when the vacation 398 response was generated. Note that this may not be the same as the 399 time the message was delivered to the user. 401 5.3. Subject 403 Users can specify the Subject of the reply with the ":subject" 404 parameter. If the :subject parameter is not supplied, then the 405 subject is generated as follows: The subject is set to the characters 406 "Auto: " followed by the original subject. 408 5.4. From 410 Unless explicitly overridden with a :from parameter, the From field 411 SHOULD be set to the address of the owner of the Sieve script. 413 5.5. To 415 The To field SHOULD be set to the address of the recipient of the 416 response. 418 5.6. Auto-submitted 420 An Auto-Submitted field with a value of "auto-replied" SHOULD be 421 included in the message header of any vacation message sent. 423 5.7. Message Body 425 The body of the message is taken from the reason string in the 426 vacation command. 428 5.8. In-Reply-To and References 430 Replies MUST have the In-Reply-To field set to the Message-ID of the 431 original message, and the References field SHOULD be updated with the 432 Message-ID of the original message. 434 If the original message lacks a Message-ID, an In-Reply-To need not 435 be generated, and References need not be changed. 437 6. Relationship to Recommendations for Automatic Responses to 438 Electronic Mail 440 The vacation extension implements a "Personal Responder" in the 441 terminology defined in [RFC3834]. Care has been taken in this 442 specification to comply with the recommendations [RFC3834] makes in 443 regards to how personal responders should behave. 445 7. Security Considerations 446 It is critical that implementations correctly implement the behavior 447 and restrictions described throughout this document. Replies MUST 448 NOT be sent out in response to messages not sent directly to the 449 user, and replies MUST NOT be sent out more often than the :days 450 argument states unless the script changes. 452 If mail is forwarded from a site that uses subaddressing, it may be 453 impossible to list all recipient addresses with ":addresses". 455 Security issues associated with mail auto-responders are fully 456 discussed in the security consideration section of [RFC3834]. This 457 document is believed not to introduce any additional security 458 considerations in this general area. 460 8. IANA Considerations 462 The following template specifies the IANA registration of the 463 vacation Sieve extension specified in this document: 465 To: iana@iana.org 466 Subject: Registration of new Sieve extension 468 Capability name: vacation 469 Capability keyword: vacation 470 Capability arguments: N/A 471 Standards Track/IESG-approved experimental RFC number: this RFC 472 Person and email address to contact for further information: 473 Ned Freed 474 E-Mail: ned.freed@mrochek.com 476 This information should be added to the list of Sieve extensions 477 given on http://www.iana.org/assignments/sieve-extensions. 479 9. References 481 9.1. Normative References 483 [I-D.ietf-sieve-3028bis] 484 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 485 Language", draft-ietf-sieve-3028bis-04 (work in progress), 486 July 2005, . 489 [I-D.ietf-sieve-variables] 490 Homme, K., "Sieve Mail Filtering Language: Variables 491 Extension", draft-ietf-sieve-variables-04 (work in 492 progress), July 2005, . 495 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 496 Extensions (MIME) Part One: Format of Internet Message 497 Bodies", RFC 2045, November 1996. 499 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 500 Part Three: Message Header Extensions for Non-ASCII Text", 501 RFC 2047, November 1996. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 507 April 2001. 509 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 510 Extension for Delivery Status Notifications (DSNs)", 511 RFC 3461, January 2003. 513 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 514 Electronic Mail", RFC 3834, August 2004. 516 9.2. Informative References 518 [I-D.ietf-sieve-refuse-reject] 519 Elvey, M. and A. Melnikov, "The SIEVE mail filtering 520 language - reject and refuse extensions", 521 draft-ietf-sieve-refuse-reject (work in progress), 522 May 2005, . 525 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 526 FUNCTIONS", RFC 2142, May 1997. 528 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 529 for Core Mail List Commands and their Transport through 530 Message Header Fields", RFC 2369, July 1998. 532 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 533 and Namespace for the Identification of Mailing Lists", 534 RFC 2919, March 2001. 536 Appendix A. Acknowledgements 537 This extension is obviously inspired by Eric Allman's vacation 538 program under Unix. The authors owe a great deal to Carnegie Mellon 539 University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil 540 Torgrim Homme, Arnt Gulbrandsen, Mark Mallet, Alexey Melnikov, 541 Jeffrey Hutzelman and many others whose names have been lost during 542 the inexcusably long gestation period of this document. 544 Authors' Addresses 546 Tim Showalter 547 ?? 549 Email: tjs@psaux.com 551 Ned Freed (editor) 552 Sun Microsystems 553 3401 Centrelake Drive, Suite 410 554 Ontario, CA 92761-1205 555 USA 557 Phone: +1 909 457 4293 558 Email: ned.freed@mrochek.com 560 Intellectual Property Statement 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Disclaimer of Validity 586 This document and the information contained herein are provided on an 587 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 588 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 589 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 590 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 591 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 592 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 594 Copyright Statement 596 Copyright (C) The Internet Society (2005). This document is subject 597 to the rights, licenses and restrictions contained in BCP 78, and 598 except as set forth therein, the authors retain all their rights. 600 Acknowledgment 602 Funding for the RFC Editor function is currently provided by the 603 Internet Society.