idnits 2.17.1 draft-newman-lemonade-burl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3463, but the abstract doesn't seem to mention this, which it should. 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). (Using the creation date from RFC3463, updated by this document, for RFC5378 checks: 2001-06-19) -- 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 (July 12, 2004) is 7200 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) ** Obsolete normative reference: RFC 1652 (ref. '1') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2192 (ref. '3') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2476 (ref. '6') (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2554 (ref. '7') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2821 (ref. '8') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3501 (ref. '12') (Obsoleted by RFC 9051) == Outdated reference: A later version (-08) exists of draft-ietf-lemonade-urlauth-00 -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '14') (Obsoleted by RFC 4120, RFC 6649) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Newman 2 Internet-Draft Sun Microsystems 3 Updates: 3463 (if approved) July 12, 2004 4 Expires: January 10, 2005 6 Message Submission BURL Extension 7 draft-newman-lemonade-burl-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 10, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 The submission profile of Simple Mail Transfer Protocol (SMTP) 39 provides a standard way for an email client to submit a complete 40 message for delivery. This specification extends the submission 41 profile by adding a new BURL command which can be used to fetch 42 submission data from an Internet Message Access Protocol (IMAP) 43 server. This permits a mail client to inject content from an IMAP 44 server into the SMTP infrastructure without downloading it to the 45 client and uploading it back to the server. 47 Table of Contents 49 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. BURL Submission Extension . . . . . . . . . . . . . . . . . . 3 52 3.1 SMTP Submission Extension Registration . . . . . . . . . . 3 53 3.2 BURL Transaction . . . . . . . . . . . . . . . . . . . . . 4 54 3.3 The BURL IMAP Option . . . . . . . . . . . . . . . . . . . 4 55 3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 6 57 4. 8-bit and Binary . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Updates to RFC 3463 . . . . . . . . . . . . . . . . . . . . . 7 59 6. Response Codes . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 64 9.2 Informative References . . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 66 A. Document History . . . . . . . . . . . . . . . . . . . . . . . 12 67 A.1 Changes from burl-00 . . . . . . . . . . . . . . . . . . . 12 68 A.2 Changes from compose-01 . . . . . . . . . . . . . . . . . 12 69 A.3 Changes from compose-00 . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . 13 72 1. Conventions Used in this Document 74 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 75 in this document are to be interpreted as defined in "Key words for 76 use in RFCs to Indicate Requirement Levels" [2]. 78 The formal syntax use the Augmented Backus-Naur Form (ABNF) [4] 79 notation including the core rules defined in Appendix A of RFC 2234. 81 2. Introduction 83 This specification defines an extension to the standard Message 84 Submission [6] protocol to permit data to be fetched from an IMAP 85 server at message submission time. This MAY be used in conjunction 86 with the CHUNKING [10] mechanism so that chunks of the message can 87 come from an external IMAP server. This provides the ability to 88 forward an email message without first downloading it to the client. 90 3. BURL Submission Extension 92 This section defines the BURL submission extension. 94 3.1 SMTP Submission Extension Registration 96 1. The name of this submission extension is "BURL". This extends 97 the Message Submission protocol on port 587 and MUST NOT be 98 advertised by a regular SMTP [8] server on port 25 that acts as a 99 relay for incoming mail from other SMTP relays. Compliant 100 submission clients MUST attempt to use port 587 prior to falling 101 back to port 25, unless explicitly configured to do otherwise by 102 the user. 104 2. The EHLO keyword value associated with the extension is "BURL". 106 3. The BURL EHLO keyword will have zero or more arguments. The only 107 argument defined at this time is the "imap" argument, which MUST 108 be present in order to use IMAP URLs with BURL. Clients MUST 109 ignore other arguments after the BURL EHLO keyword unless they 110 are defined by a subsequent IETF standards track specification. 111 The arguments which appear after the BURL EHLO keyword may change 112 subsequent to the use of SMTP AUTH [7], so a server which 113 advertises BURL with no arguments prior to authentication 114 indicates that BURL is supported but authentication is required 115 to use it. 117 4. This extension adds the BURL SMTP verb. This verb is used as a 118 replacement for the DATA command and is only permitted during a 119 mail transaction after at least one successful recipient. 121 3.2 BURL Transaction 123 When a BURL-aware client connects to a submit server with the BURL 124 extension, it will first authenticate (using SMTP AUTH and perhaps 125 STARTTLS), and then can submit any number of messages with full 126 interoperability with important SMTP extensions such as delivery 127 status notifications [18]. 129 A simple BURL transaction will consist of MAIL FROM, one or more RCPT 130 TO headers and a BURL command with the "LAST" tag. The BURL command 131 will include an IMAP URL pointing to a fully formed message ready for 132 injection into the SMTP infrastructure. If PIPELINING [9] is 133 advertised, the client MAY send the entire transaction in one round 134 trip. If no valid RCPT TO address is supplied, the BURL command will 135 simply fail and no resolution of the BURL URL argument will be 136 performed. If at least one valid RCPT TO address is supplied, then 137 the BURL URL argument will be resolved before the server responds to 138 the command. 140 A more sophisticated BURL transaction occurs when the server also 141 advertises CHUNKING [10]. In this case, the BURL and BDAT commands 142 may be interleaved until one of them terminates the transaction with 143 the "LAST" argument. If PIPELINING [9] is also advertised, then the 144 client may pipeline the entire transaction in one round-trip. 145 However, it MUST wait for the results of the "LAST" BDAT or BURL 146 command prior to initiating a new transaction. 148 The BURL command directs the server to fetch the data object to which 149 the URL refers and include it in the message. If the URL fetch 150 fails, the server will fail the entire transaction. 152 3.3 The BURL IMAP Option 154 When "imap" is present in the space-separated list of arguments 155 following the BURL EHLO keyword, that indicates the BURL command 156 supports the URLAUTH [13] extended form of IMAP URLs [3]. 158 Subsequent to a successful SMTP AUTH command, the submission server 159 MAY indicate a pre-arranged trust relationship with a specific IMAP 160 server by including a BURL EHLO keyword argument of the form "imap:// 161 imap.example.com". In this case, the submission server will permit a 162 regular IMAP URL to mailboxes on imap.example.com which the user who 163 authenticated to the submit server can access. 165 3.4 Examples 167 In examples, "C:" and "S:" indicate lines sent by the client and 168 server respectively. If a single "C:" or "S:" label applies to 169 multiple lines, then the line breaks between those lines are for 170 editorial clarity only and are not part of the actual protocol 171 exchange. 173 Two successful submissions (without and with pipelining) follow: 175 176 C: EHLO potter.example.com 177 S: 250-owlry.example.com 178 S: 250-8BITMIME 179 S: 250-BURL imap 180 S: 250-AUTH PLAIN 181 S: 250-DSN 182 S: 250 ENHANCEDSTATUSCODES 183 C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 184 S: 235 2.7.0 PLAIN authentication successful. 185 C: MAIL FROM: 186 S: 250 2.5.0 Address Ok. 187 C: RCPT TO: 188 S: 250 2.1.5 ron@gryffindor.example.com OK. 189 C: BURL imap://harry@gryffindor.example.com/outbox 190 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry 191 :internal:91354a473744909de610943775f92038 LAST 192 S: 250 2.5.0 Ok. 194 195 C: EHLO potter.example.com 196 S: 250-owlry.example.com 197 S: 250-8BITMIME 198 S: 250-PIPELINING 199 S: 250-BURL imap 200 S: 250-AUTH PLAIN 201 S: 250-DSN 202 S: 250 ENHANCEDSTATUSCODES 203 C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 204 C: MAIL FROM: 205 C: RCPT TO: 206 C: BURL imap://harry@gryffindor.example.com/outbox 207 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry 208 :internal:91354a473744909de610943775f92038 LAST 209 S: 235 2.7.0 PLAIN authentication successful. 210 S: 250 2.5.0 Address Ok. 211 S: 250 2.1.5 ron@gryffindor.example.com OK. 212 S: 250 2.5.0 Ok. 214 Some example failure cases: 216 C: MAIL FROM: 217 C: RCPT TO: 218 C: BURL imap://harry@gryffindor.example.com/outbox 219 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry 220 :internal:91354a473744909de610943775f92038 LAST 221 S: 250 2.5.0 Address Ok. 222 S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com 223 S: 554 5.5.0 No recipients have been specified. 225 C: MAIL FROM: 226 C: RCPT TO: 227 C: BURL imap://harry@gryffindor.example.com/outbox 228 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry 229 :internal:71354a473744909de610943775f92038 LAST 230 S: 250 2.5.0 Address Ok. 231 S: 250 2.1.5 ron@gryffindor.example.com OK. 232 S: 554 5.7.0 IMAP URL authorization failed 234 3.5 Formal Syntax 236 The following syntax specification inherits ABNF [4] and Uniform 237 Resource Identifiers [5]. 239 burl-param = "imap" / ("imap://" authority) 240 ; parameter to BURL EHLO keyword 242 burl-cmd = "BURL" SP absoluteURI [SP end-marker] CRLF 244 end-marker = "LAST" 246 4. 8-bit and Binary 248 A submit server which advertises BURL MUST also advertise 8BITMIME 249 [1] and perform the down conversion described in that specification 250 on the resulting complete message if 8-bit data is received with the 251 BURL command and passed to a 7-bit server. If the URL argument to 252 BURL refers to binary data, then the submit server MAY refuse the 253 command or down convert as described in Binary SMTP [10]. 255 The Submit server MAY refuse to accept a BURL command or combination 256 of BURL and BDAT commands which result in unencoded 8-bit data in 257 mail or MIME [16] headers. Alternatively, the server MAY accept such 258 data and down convert to MIME header encoding [17]. 260 5. Updates to RFC 3463 262 SMTP or Submit servers which advertise ENHANCEDSTATUSCODES [15] may 263 includes enhanced status codes defined in RFC 3463 [19]. The BURL 264 extension introduces new error cases which that RFC did not consider. 265 The following additional enhanced status codes are defined by this 266 specification: 268 X.6.6 Message content not available 270 The message content could not be fetched from a remote system. 271 This may be useful as a permanent or persistent temporary 272 notification. 274 X.7.8 Trust relationship required 276 The submission server requires a configured trust relationship 277 with a third-party server in order to access the message content. 279 6. Response Codes 281 This section includes example response codes to the BURL command. 282 Other text may be used with the same response codes. This list is 283 not exhaustive and BURL clients MUST tolerate any valid SMTP response 284 code. Most of these examples include the appropriate enhanced status 285 code [19]. 287 554 5.5.0 No recipients have been specified 289 This response code occurs when BURL is used with PIPELINING and 290 all RCPT TOs failed. 292 503 5.5.0 Valid RCPT TO required before BURL 294 This response code is an alternative to the previous one when BURL 295 is used with PIPELINING and all RCPT TOs failed. 297 554 5.6.3 Conversion required but not supported 299 This response code occurs when the URL points to binary data and 300 the implementation does not support down conversion to base64. 301 This can also be used if the URL points to message data with 8-bit 302 content in headers and the server does not down convert such 303 content. 305 554 5.3.4 Message too big for system 307 The message (subsequent to URL resolution) is larger than the 308 per-message size limit for this server. 310 554 5.7.8 URL resolution requires trust relationship 312 The submit server does not have a trust relationship with the IMAP 313 server specified in the URL argument to BURL. 315 552 5.2.2 Mailbox full 317 The recipient is local, the submit server supports direct delivery 318 and the recipient has exceeded his quota and any grace period for 319 delivery attempts. 321 554 5.6.6 IMAP URL resolution failed 323 The IMAP FETCHURL command returned an error or no data. 325 354 Waiting for additional BURL or BDAT commands 327 A BURL command without the "LAST" modifier was sent. The URL for 328 this BURL command was successfully resolved, but the content will 329 not be committed to persistent storage until the rest of the 330 message content is collected. For example, a Unix server may have 331 written the content to a queue file buffer, but not yet performed 332 an fsync() operation. If the server loses power, the content can 333 still be lost. 335 451 4.4.1 IMAP server unavailable 337 The connection to the IMAP server to resolve the URL failed. 339 250 2.5.0 Ok. 341 The URL was successfully resolved and the complete message data 342 has been committed to persistent storage. 344 250 2.6.4 MIME header conversion with loss performed 346 The URL pointed to message data which included mail or MIME 347 headers with 8-bit data. This data was converted to MIME header 348 encoding [17] but the submit server may not have correctly guessed 349 the unlabelled character set. 351 7. IANA Considerations 353 When this is published as an RFC, the "BURL" SMTP extension as 354 described in Section 3 will be registered. This registration will be 355 marked for use by message submission [6] only in the registry. 357 8. Security Considerations 359 Modern SMTP submission servers often include content-based security 360 and denial-of-service defense mechanisms such as virus filtering, 361 size limits, server-generated signatures, spam filtering, etc. 362 Implementations of BURL should fetch the URL content prior to 363 application of such content-based mechanisms in order to preserve 364 their function. 366 Clients which generate unsolicited bulk email or email with viruses 367 could use this mechanism to compensate for a slow link between the 368 client and submit server. In particular, this mechanism would make 369 it feasible for a programmable cell phone or other device on a slow 370 link to become a significant source of unsolicited bulk email and/or 371 viruses. This makes it more important for submit server vendors 372 implementing BURL to have auditing and/or defenses against such 373 denial-of-service attacks including mandatory authentication, logging 374 which associates unique client identifiers with mail transactions, 375 limits on re-use of the same IMAP URL, rate limits, recipient count 376 limits and content filters. 378 Transfer of the URLAUTH [13] form of IMAP URLs in the clear can 379 expose the authorization token to network eavesdroppers. 380 Implementations which support such URLs can address this issue by 381 using a strong confidentiality protection mechanism. For example, 382 the SMTP STARTTLS [11] and the IMAP STARTTLS [12] extensions in 383 combination with a configuration setting which requires their use 384 with such IMAP URLs would address this concern. 386 Use of a pre-arranged trust relationship between a submit server and 387 a specific IMAP server introduces security considerations: a 388 compromise of the submit server should not automatically compromise 389 all accounts on the IMAP server so trust relationships involving 390 super-user proxy credentials are strongly discouraged. A system 391 which requires the submit server to authenticate to the IMAP server 392 with submit credentials and subsequently requires a URLAUTH URL to 393 fetch any content addresses this concern. A trusted third party 394 model for proxy credentials such as that provided by Kerberos5 [14] 395 would also suffice. 397 When a client uses SMTP STARTTLS to send a BURL command which 398 references non-public information there is a user expectation that 399 the entire message content will be treated confidentially. To 400 address this expectation, the message submission server should use 401 STARTTLS or a mechanism providing equivalent data confidentiality 402 when fetching the content referenced by that URL. 404 A legitimate user of a submit server may try to compromise other 405 accounts on the server by providing an IMAP URLAUTH URL which points 406 to a server under that user's control which is designed to undermine 407 the security of the submit server. For this reason, the IMAP client 408 code which the submit server uses must be robust with respect to 409 arbitrary input sizes (including large IMAP literals) and arbitrary 410 delays from the IMAP server. Requiring a pre-arranged trust 411 relationship between a submit server and the IMAP server also 412 addresses this concern. 414 9. References 416 9.1 Normative References 418 [1] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, 419 "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 420 1994. 422 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 423 Levels", BCP 14, RFC 2119, March 1997. 425 [3] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 427 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 428 Specifications: ABNF", RFC 2234, November 1997. 430 [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 431 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 432 1998. 434 [6] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, 435 December 1998. 437 [7] Myers, J., "SMTP Service Extension for Authentication", RFC 438 2554, March 1999. 440 [8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 441 2001. 443 [9] Freed, N., "SMTP Service Extension for Command Pipelining", STD 444 60, RFC 2920, September 2000. 446 [10] Vaudreuil, G., "SMTP Service Extensions for Transmission of 447 Large and Binary MIME Messages", RFC 3030, December 2000. 449 [11] Hoffman, P., "SMTP Service Extension for Secure SMTP over 450 Transport Layer Security", RFC 3207, February 2002. 452 [12] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 453 4rev1", RFC 3501, March 2003. 455 [13] Crispin, M. and C. Newman, "Internet Message Access Protocol 456 (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth-00 457 (work in progress), July 2004. 459 9.2 Informative References 461 [14] Kohl, J. and B. Neuman, "The Kerberos Network Authentication 462 Service (V5)", RFC 1510, September 1993. 464 [15] Freed, N., "SMTP Service Extension for Returning Enhanced Error 465 Codes", RFC 2034, October 1996. 467 [16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 468 Extensions (MIME) Part One: Format of Internet Message Bodies", 469 RFC 2045, November 1996. 471 [17] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 472 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 473 November 1996. 475 [18] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 476 Extension for Delivery Status Notifications (DSNs)", RFC 3461, 477 January 2003. 479 [19] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, 480 January 2003. 482 Author's Address 484 Chris Newman 485 Sun Microsystems 486 1050 Lakes Drive 487 West Covina, CA 91790 488 US 490 EMail: chris.newman@sun.com 492 Appendix A. Document History 494 Note to RFC Editor: delete this section before publication as an RFC. 496 A.1 Changes from burl-00 498 o Enhanced security considerations section 500 o Updated URLAUTH reference 502 o Added updates to RFC 3463 504 o Added Response Codes section 506 A.2 Changes from compose-01 508 o Removed the conversion argument to BURL to simplify. 510 o Replace the conversion section with the simpler 8-bit and Binary 511 section. 513 o Removed the failhow argument to simplify and eliminate 514 race-condition which bothered people. 516 o Simplify specification to eliminate "composition" model and just 517 focus on BURL command. 519 o Make it clear that BURL can be used without the chunking 520 extension. 522 A.3 Changes from compose-00 524 o Added the end-marker "LAST", so this could be used without BDAT 525 and works with a pre-composed message. 527 o Changed "Message Composition" to "Message Submission with 528 Composition" in several places. 530 o Correct Spelling Errors 532 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 intellectual property or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; neither does it represent that it 539 has made any effort to identify any such rights. Information on the 540 IETF's procedures with respect to rights in standards-track and 541 standards-related documentation can be found in BCP-11. Copies of 542 claims of rights made available for publication and any assurances of 543 licenses to be made available, or the result of an attempt made to 544 obtain a general license or permission for the use of such 545 proprietary rights by implementors or users of this specification can 546 be obtained from the IETF Secretariat. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary 550 rights which may cover technology that may be required to practice 551 this standard. Please address the information to the IETF Executive 552 Director. 554 Full Copyright Statement 556 Copyright (C) The Internet Society (2004). All Rights Reserved. 558 This document and translations of it may be copied and furnished to 559 others, and derivative works that comment on or otherwise explain it 560 or assist in its implementation may be prepared, copied, published 561 and distributed, in whole or in part, without restriction of any 562 kind, provided that the above copyright notice and this paragraph are 563 included on all such copies and derivative works. However, this 564 document itself may not be modified in any way, such as by removing 565 the copyright notice or references to the Internet Society or other 566 Internet organizations, except as needed for the purpose of 567 developing Internet standards in which case the procedures for 568 copyrights defined in the Internet Standards process must be 569 followed, or as required to translate it into languages other than 570 English. 572 The limited permissions granted above are perpetual and will not be 573 revoked by the Internet Society or its successors or assignees. 575 This document and the information contained herein is provided on an 576 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 577 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 578 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 579 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 580 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 582 Acknowledgment 584 Funding for the RFC Editor function is currently provided by the 585 Internet Society.