idnits 2.17.1 draft-ietf-sieve-vacation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** 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 == Line 184 has weird spacing: '... of the messa...' == Line 263 has weird spacing: '...set the recor...' == 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 (October 11, 2005) is 6773 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: 'I-D.ietf-sieve-refuse-reject' is defined on line 550, 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) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: April 14, 2006 Sun Microsystems 6 October 11, 2005 8 Sieve Email Filtering: Vacation Extension 9 draft-ietf-sieve-vacation-04 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 April 14, 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 16. Added reference to RFC 2822 section 3.6.4 - explains how to 85 construct references fields. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Conventions used in this document . . . . . . . . . . . . . . 4 91 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 92 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 93 4.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 94 4.2 Previous Response Tracking . . . . . . . . . . . . . . . . 5 95 4.3 Subject and from parameters . . . . . . . . . . . . . . . 7 96 4.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 97 4.5 Address Parameter and Limiting Replies to Personal 98 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 99 4.6 Restricting Replies to Automated Processes and Mailing 100 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 101 4.7 Interaction with Other Sieve Actions . . . . . . . . . . . 9 102 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 103 5. Response Message Generation . . . . . . . . . . . . . . . . . 10 104 5.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 105 5.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 106 5.3 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 107 5.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 108 5.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 109 5.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 110 5.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 111 5.8 In-Reply-To and References . . . . . . . . . . . . . . . . 11 112 6. Relationship to Recommendations for Automatic Responses to 113 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 116 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 117 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 118 9.2 Informative References . . . . . . . . . . . . . . . . . . 13 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 120 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 121 Intellectual Property and Copyright Statements . . . . . . . . 15 123 1. Introduction 125 This document defines an extension to the Sieve language defined in 126 [I-D.ietf-sieve-3028bis] for notification that messages to a 127 particular recipient will not be answered immediately. 129 2. Conventions used in this document 131 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 132 1.1. 134 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED" 135 and "MAY" in this document are to be interpreted as defined in 136 [RFC2119]. 138 3. Capability Identifier 140 Sieve implementations that implement vacation have an identifier of 141 "vacation" for use with the capability mechanism. 143 4. Vacation Action 145 Usage: vacation [":days" number] [":subject" string] 146 [":from" string] [":addresses" string-list] 147 [":mime"] [":handle" string] 149 The "vacation" action implements a vacation autoresponder similar to 150 the vacation command available under many versions of Unix. Its 151 purpose is to provide correspondents with notification that the user 152 is away for an extended period of time and that they should not 153 expect quick responses. 155 "Vacation" is used to respond to a message with another message. 156 Vacation's messages are always addressed to the Return-Path address 157 (that is, the envelope from address) of the message being responded 158 to. 160 4.1 Days Parameter 162 The ":days" argument is used to specify the period in which addresses 163 are kept and are not responded to, and is always specified in days. 164 The minimum value used for this parameter is normally 1. Sites MAY 165 define a different minimum value as long as the minimum is greater 166 than 0. Sites MAY also define a maximum days value, which MUST be 167 greater than 7, and SHOULD be greater than 30. 169 If ":days" is omitted, the default value is either 7 or the minimum 170 value (as defined above), whichever is greater. 172 If the parameter given to ":days" is less than the minimum value, 173 then the minimum value is used instead. 175 If ":days" exceeds the site-defined maximum, the site-defined maximum 176 is used instead. 178 4.2 Previous Response Tracking 180 "Vacation" keeps track of all of the responses it has sent to each 181 address in some period (as specified by the :days optional argument). 182 If vacation has not previously sent the response to this address 183 within the given time period, it sends the "reason" argument to the 184 SMTP MAIL FROM address [RFC2821] of the message that is being 185 responded to. (The SMTP MAIL FROM address should be available in the 186 Return-path: header field if Sieve processing occurs after final 187 delivery.) 189 Tracking is not just per address, but must also take the vacation 190 response itself into account. A script writer might, for example, 191 have a vacation action that will send a general notice only once in 192 any two-week period. However, even if a sender has received this 193 general notice, it may be important to send a specific notice when a 194 message about something timely or something specific has been 195 detected. 197 A particular vacation response can be identified in one of two ways. 198 The first way is via an explicit :handle argument, which attaches a 199 name to the response. All vacation statements that use the same 200 handle will be considered to be the same response for tracking 201 purposes. 203 The second way is via a synthesis of the :subject, :from, :mime, and 204 reason vacation command arguments. All vacation actions that do not 205 contain an explicit handle and which use an identical combination of 206 these arguments are considered to be the same for tracking purposes. 208 For instance, If coyote@desert.example.org sends mail to 209 roadrunner@acme.example.com twice, once with the subject "Cyrus bug" 210 and once with the subject "come over for dinner", and 211 roadrunner@acme.example.com has the script shown below, 212 coyote@desert.example.org would receive two responses, once with the 213 first message, once with the second. 215 require "vacation"; 216 if header :contains "subject" "cyrus" { 217 vacation "I'm out -- send mail to cyrus-bugs"; 218 } else { 219 vacation "I'm out -- call me at 304 555 1212"; 221 } 223 In the above example, coyote@desert.example.org gets the second 224 message despite having gotten the first one because separate vacation 225 responses have been triggered. This behavior is REQUIRED. 227 There is one important exception to this rule, however. If the sieve 228 variables extension [I-D.ietf-sieve-variables] is used, the arguments 229 MUST NOT have undergone variable expansion prior to their use in 230 response tracking. This is so that examples like the following 231 script will only generate a single response to each incoming message 232 with a different subject line. 234 require ["vacation", "variables"]; 235 if header :matches "subject" "*" { 236 vacation :subject "Automatic response to: ${1}" 237 "I'm away -- send mail to foo in my absence"; 238 } 240 As noted above, the optional ":handle" parameter can be used to tell 241 the Sieve interpreter to treat two vacation actions with different 242 arguments as the same command for purposes of response tracking. The 243 argument to ":handle" is a string that identifies the type of 244 response being sent. For instance, if tweety@cage.example.org sends 245 mail to spike@doghouse.example.com twice, one with the subject 246 "lunch?" and once with the subject "dinner?", and 247 spike@doghouse.example.com has the script shown below, 248 tweety@cage.example.org will only receive a single response. (Which 249 response is sent depends on the order in which the messages are 250 processed.) 252 require "vacation"; 253 if header :contains "subject" "lunch" { 254 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 255 } else { 256 vacation :handle "ran-away" "I'm out"; 257 } 259 NOTE: One way to implement the necessary mechanism here is to store a 260 hash of either the current handle and the recipient address or, if no 261 handle is provided, a hash of the vacation action parameters 262 specifying the message content and the recipient address. If a 263 script is changed, implementations MAY reset the records of who has 264 been responded to and when they have been responded to. 266 Implementations are free to limit the number of remembered responses, 267 provided the limit is no less than 1000. When limiting the number of 268 tracked responses, implementations SHOULD discard the oldest ones 269 first. 271 4.3 Subject and from parameters 273 The ":subject" parameter specifies a subject line to attach to any 274 vacation response that is generated. UTF-8 characters can be used in 275 the string argument; implementations MUST convert the string to 276 [RFC2047] encoded words if and only if non-ASCII characters are 277 present. Implementations MUST generate an appropriate default 278 subject line as specified below if no :subject parameter is 279 specified. 281 A ":from" parameter may be used to specify an alternate address to 282 use in the From field of vacation messages. The string must specify 283 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 284 syntax and generate an error when a syntactically invalid ":from" 285 parameter is specified. Implementations MAY also impose restrictions 286 on what addresses can specified in a ":from" parameter; it is 287 suggested that values which fail such a security check simply be 288 ignored rather than causing the vacation action to fail. 290 4.4 MIME Parameter 292 The ":mime" parameter, if supplied, specifies that the reason string 293 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 294 including both MIME headers and content. 296 If the optional :mime parameter is not supplied, the reason string is 297 considered to be a UTF-8 string. 299 require "vacation"; 300 vacation :mime text: 301 Content-Type: multipart/alternative; boundary=foo 303 --foo 305 I'm at the beach relaxing. Mmmm, surf... 307 --foo 308 Content-Type: text/html; charset=us-ascii 310 312 How to relax 313 314

I'm at the beach relaxing. 315 Mmmm, surf... 316 318 --foo-- 319 . 321 4.5 Address Parameter and Limiting Replies to Personal Messages 323 "Vacation" MUST NOT respond to a message unless the recipient user's 324 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 325 "Resent-Bcc" line of the original message. An email address is 326 considered to belong to the recipient if it is one of: 328 1. An email address known by the implementation to be associated 329 with the recipient, 331 2. the final envelope recipient address if it's available to the 332 implementation, or 334 3. an address specified by the script writer via the ":addresses" 335 argument described in the next paragraph. 337 Users can supply additional mail addresses that are theirs with the 338 ":addresses" argument, which takes a string-list listing additional 339 addresses that a user might have. These addresses are considered to 340 belong to the recipient user in addition to the addresses known to 341 the implementation. 343 4.6 Restricting Replies to Automated Processes and Mailing Lists 345 Implementations MUST have a list of addresses that "vacation" MUST 346 NOT send mail to. However, the contents of this list are 347 implementation defined. The purpose of this list is to stop mail 348 from going to addresses used by system daemons that would not care if 349 the user is actually reading her mail. 351 Implementations are encouraged, however, to include well-known 352 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 353 addresses typically used only by automated systems. Additionally, 354 addresses ending in "-request" or beginning in "owner-", i.e., 355 reserved for mailing list software, are also suggested. 357 Implementors may take guidance from [RFC2142], but should be careful. 358 Some addresses, like "POSTMASTER", are generally actually managed by 359 people, and people do care if the user is going to be unavailable. 361 Implementations SHOULD NOT respond to any message that contains a 362 "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- 363 Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] 364 header field. 366 Implementations SHOULD NOT respond to any message that has an "Auto- 367 submitted" header field with a value other than "no". This header 368 field is described in [RFC3834]. 370 4.7 Interaction with Other Sieve Actions 372 Vacation does not affect Sieve's implicit keep action. 374 Vacation can only be executed once per script. A script will fail if 375 it attempts to execute two or more vacation actions. 377 Implementations MUST NOT consider vacation used with discard, keep, 378 fileinto, or redirect an error. The vacation action is incompatible 379 with the sieve reject and refuse actions [I-D.ietf-sieve-refuse- 380 reject]. 382 4.8 Examples 384 Here is a simple use of vacation. 386 require "vacation"; 387 vacation :days 23 :addresses ["tjs@example.edu", 388 "ts4z@landru.example.edu"] 389 "I'm away until October 19. 390 If it's an emergency, call 911, I guess." ; 392 By mingling vacation with other rules, users can do something more 393 selective. 395 require "vacation"; 396 if header :contains "from" "boss@example.edu" { 397 redirect "pleeb@isp.example.org"; 398 } else { 399 vacation "Sorry, I'm away, I'll read your 400 message when I get around to it."; 401 } 403 5. Response Message Generation 405 This section details the requirements for the generated response 406 message. 408 It is worth noting that the input message and arguments may be in 409 UTF-8, and that implementations MUST deal with UTF-8 input, although 410 implementations MAY transcode to other character sets as regional 411 taste dictates. When :mime is used the reason argument also contains 412 MIME header information. The headers must conform to MIME 413 conventions; in particular, 8bit text is not allowed. 414 Implementations SHOULD reject vacation :mime actions containing 8bit 415 header material. 417 5.1 SMTP MAIL FROM address 419 The SMTP MAIL FROM address of the message envelope SHOULD be set to 420 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 421 SMTP transaction if the NOTARY SMTP extension [RFC3461] is available. 423 5.2 Date 425 The Date field SHOULD be set to the date and time when the vacation 426 response was generated. Note that this may not be the same as the 427 time the message was delivered to the user. 429 5.3 Subject 431 Users can specify the Subject of the reply with the ":subject" 432 parameter. If the :subject parameter is not supplied, then the 433 subject is generated as follows: The subject is set to the characters 434 "Auto: " followed by the original subject. 436 5.4 From 438 Unless explicitly overridden with a :from parameter, the From field 439 SHOULD be set to the address of the owner of the Sieve script. 441 5.5 To 443 The To field SHOULD be set to the address of the recipient of the 444 response. 446 5.6 Auto-submitted 448 An Auto-Submitted field with a value of "auto-replied" SHOULD be 449 included in the message header of any vacation message sent. 451 5.7 Message Body 453 The body of the message is taken from the reason string in the 454 vacation command. 456 5.8 In-Reply-To and References 458 Replies MUST have the In-Reply-To field set to the Message-ID of the 459 original message, and the References field SHOULD be updated with the 460 Message-ID of the original message. 462 If the original message lacks a Message-ID, an In-Reply-To need not 463 be generated, and References need not be changed. 465 Section 3.6.2 of [RFC2822] provides a complete description of how 466 References fields should be generated. 468 6. Relationship to Recommendations for Automatic Responses to 469 Electronic Mail 471 The vacation extension implements a "Personal Responder" in the 472 terminology defined in [RFC3834]. Care has been taken in this 473 specification to comply with the recommendations [RFC3834] makes in 474 regards to how personal responders should behave. 476 7. Security Considerations 478 It is critical that implementations correctly implement the behavior 479 and restrictions described throughout this document. Replies MUST 480 NOT be sent out in response to messages not sent directly to the 481 user, and replies MUST NOT be sent out more often than the :days 482 argument states unless the script changes. 484 If mail is forwarded from a site that uses subaddressing, it may be 485 impossible to list all recipient addresses with ":addresses". 487 Security issues associated with mail auto-responders are fully 488 discussed in the security consideration section of [RFC3834]. This 489 document is believed not to introduce any additional security 490 considerations in this general area. 492 8. IANA Considerations 494 The following template specifies the IANA registration of the 495 vacation Sieve extension specified in this document: 497 To: iana@iana.org 498 Subject: Registration of new Sieve extension 500 Capability name: vacation 501 Capability keyword: vacation 502 Capability arguments: N/A 503 Standards Track/IESG-approved experimental RFC number: this RFC 504 Person and email address to contact for further information: 505 Ned Freed 506 E-Mail: ned.freed@mrochek.com 508 This information should be added to the list of Sieve extensions 509 given on http://www.iana.org/assignments/sieve-extensions. 511 9. References 513 9.1 Normative References 515 [I-D.ietf-sieve-3028bis] 516 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 517 Language", draft-ietf-sieve-3028bis-04 (work in progress), 518 July 2005, . 521 [I-D.ietf-sieve-variables] 522 Homme, K., "Sieve Mail Filtering Language: Variables 523 Extension", draft-ietf-sieve-variables-04 (work in 524 progress), July 2005, . 527 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 528 Extensions (MIME) Part One: Format of Internet Message 529 Bodies", RFC 2045, November 1996. 531 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 532 Part Three: Message Header Extensions for Non-ASCII Text", 533 RFC 2047, November 1996. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 539 April 2001. 541 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 542 Extension for Delivery Status Notifications (DSNs)", 543 RFC 3461, January 2003. 545 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 546 Electronic Mail", RFC 3834, August 2004. 548 9.2 Informative References 550 [I-D.ietf-sieve-refuse-reject] 551 Elvey, M. and A. Melnikov, "The SIEVE mail filtering 552 language - reject and refuse extensions", 553 draft-ietf-sieve-refuse-reject (work in progress), 554 May 2005, . 557 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 558 FUNCTIONS", RFC 2142, May 1997. 560 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 561 for Core Mail List Commands and their Transport through 562 Message Header Fields", RFC 2369, July 1998. 564 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 565 April 2001. 567 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 568 and Namespace for the Identification of Mailing Lists", 569 RFC 2919, March 2001. 571 Authors' Addresses 573 Tim Showalter 574 ?? 576 Email: tjs@psaux.com 577 Ned Freed (editor) 578 Sun Microsystems 579 3401 Centrelake Drive, Suite 410 580 Ontario, CA 92761-1205 581 USA 583 Phone: +1 909 457 4293 584 Email: ned.freed@mrochek.com 586 Appendix A. Acknowledgements 588 This extension is obviously inspired by Eric Allman's vacation 589 program under Unix. The authors owe a great deal to Carnegie Mellon 590 University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil 591 Torgrim Homme, Arnt Gulbrandsen, Mark Mallet, Alexey Melnikov, 592 Jeffrey Hutzelman, Philip Guenther and many others whose names have 593 been lost during the inexcusably long gestation period of this 594 document. 596 Intellectual Property Statement 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 This document and the information contained herein are provided on an 623 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 624 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 625 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 626 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 627 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Copyright Statement 632 Copyright (C) The Internet Society (2005). This document is subject 633 to the rights, licenses and restrictions contained in BCP 78, and 634 except as set forth therein, the authors retain all their rights. 636 Acknowledgment 638 Funding for the RFC Editor function is currently provided by the 639 Internet Society.