idnits 2.17.1 draft-burger-smtp-rdlv-01.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 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. ** 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 91 has weird spacing: '...emented appli...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 03, 2005) is 6865 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: 'PIPELINING' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC2034' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC3463' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2033 ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) -- Duplicate reference: RFC3464, mentioned in 'RFC3464', was also mentioned in 'RFC3463'. Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual E. Burger 3 Internet-Draft Brooktrout Technology, Inc. 4 Expires: January 4, 2006 A. Melnikov 5 Isode Ltd. 6 July 03, 2005 8 SMTP Service Extension for Reliable Delivery 9 draft-burger-smtp-rdlv-01 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 January 4, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 There is an issue with SMTP that RFC 1047 raised in 1988. The time 43 between a SMTP client submitting a mail object and the SMTP server 44 responding to the request can be arbitrarily long. SMTP addresses 45 this issue by a hack, hoping that the SMTP server responds fast 46 enough and the SMTP client waits long enough to find out if the 47 submission was successful. 49 Unfortunately, this approach is, by its nature, unreliable. Besides 50 the duplicate delivery problem identified by RFC 1047, this behavior 51 introduces serious human factors problems for submission servers. 53 This document describes a SMTP Service Extension that enables the 54 SMTP client to reliably know that the SMTP server is alive, well, and 55 working on the message submission. 57 Conventions used in this document 59 RFC 2119 [RFC2119] provides the interpretations for the key words 60 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 61 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this 62 document. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Overview of the Extension . . . . . . . . . . . . . . . . . . 4 68 3. Formal Description of the Extension . . . . . . . . . . . . . 4 69 3.1 Extension Definition . . . . . . . . . . . . . . . . . . . 4 70 3.2 Extension Operation . . . . . . . . . . . . . . . . . . . 5 71 3.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 5 72 3.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 6 73 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1 Long Submit . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.2 Unsupported Verb . . . . . . . . . . . . . . . . . . . . . 8 78 6.3 Remote Submit . . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 82 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 84 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 85 Intellectual Property and Copyright Statements . . . . . . . . 13 87 1. Introduction 89 The Simple Mail Transfer Protocol, SMTP [RFC2821], has over twenty 90 years of field experience. SMTP is one of the most widely 91 implemented application protocols in the Internet. Virtually every 92 Internet host of every kind -- mainframe, minicomputer, 93 microcomputer, PDA, or even wristwatch -- interacts with the Internet 94 Mail system. 96 RFC 1047 [RFC1047] identified a problem with the message submission 97 protocol in SMTP. Namely, the SMTP server has to guarantee that it 98 has responsibility for the message once it issues the 250 response at 99 the end of the DATA request. However, the time from the final dot 100 indicating the end of the DATA request to the actual 250 response can 101 be arbitrarily long. 103 From the perspective of the SMTP client, it cannot discern between 104 the following situations: 105 o The SMTP server process has crashed, but the TCP connection is 106 still up. 107 o The SMTP host has crashed, but the TCP connection has not yet 108 timed-out. 109 o The SMTP server is under great load, and will get to the message 110 soon. 111 o The message is "big" in some respect, such as message size or 112 number of recipients. Thus the SMTP server, even under normal 113 circumstances, requires a significant amount of time to process 114 the message. 115 The approach espoused by RFC 2821 is for the server to respond as 116 fast as possible to the request and for the client to wait long 117 enough for the response. 119 Over the years, this has been the staple approach. RFC 1123 120 [RFC1123] reiterates that the server should respond "quickly" and the 121 client should "wait long enough." LMTP [RFC2033] shares the syntax 122 of SMTP, and shares the submission timeout problem. The advice 123 offered in LMTP is that if it will take a long time to submit an 124 object, one should not use LMTP. Even RFC 3464 [RFC3464] on Delivery 125 Status Notifications, points out that duplicate submissions can occur 126 and one should just "live with it." 128 Besides the obvious problem of an unreliable protocol, in the 129 Lemonade working group we have run into a human factors problem made 130 worse by this time out issue. There are extensions being proposed, 131 such as BURL [burl], which can suffer from the same lack of protocol 132 support for long requests. This impacts the user's experience, 133 especially when they have intermittent connectivity, as experienced 134 on wide-area wireless networks. The user has no idea if a submission 135 request is taking a long time because the server needs a long time or 136 if they have lost their connection. 138 What we need is a method for the SMTP server to inform the SMTP 139 client that the server is alive and still working on the submission. 141 2. Overview of the Extension 143 This document introduces the RDLV extension. When indicated, SMTP 144 servers implementing the RDLV extension periodically issue a 120 145 response. The SMTP client then issues a CONT command to continue the 146 operation. 147 DISCUSSION POINT: Ideally, the response should be truly 148 preliminary and not change the SMTP state machine. If the server 149 is under load, the last thing it needs is more handshake protocol 150 actions to perform. I could see having the server simply 151 periodically issuing 120 responses. However, in this case neither 152 RSET to cancel nor DETA to detach would work. Moreover, the 153 proposal in this document follows the VERB-RESULT model of SMTP. 154 Periodic emission of 120's changes the model to VERB- 155 InterimRESULT-InterimRESULT-FinalRESULT. On the other hand, This 156 extension adds sub-states to potentially all long commands, which 157 is a major change, as well. 159 3. Formal Description of the Extension 161 3.1 Extension Definition 163 1. The text name of this SMTP service extension is "Reliable 164 Delivery". 165 2. The EHLO keyword associated with this SMTP service extension is 166 "RDLV". 167 3. The RDLV EHLO keyword has one parameter, mintimer. Mintimer 168 specifies the minimum amount of time in integer seconds the 169 server will wait before issuing a 120 response to a long command. 170 4. This extension doesn't add any new parameters to MAIL or RCPT 171 commands. 172 5. This document defines a new SMTP verb, RDLV. The RDLV verb 173 indicates that the following transmission verb, such as DATA, 174 BDAT [RFC3030], and so on is to use the procedures described in 175 this document for generating 120 responses. 176 DISCUSSION POINT: We are really describing an adverb here, 177 not a verb. On the one hand, this should be a new parameter 178 to each of the "takes a long time" verbs. On the other hand, 179 it is much easier to describe the behavior if we keep them 180 separate. 182 Conversely, we could define RDLV to be for the entire session, 183 not just the following command. What do we think of that? 184 6. The RDLV verb takes a single parameter, maxtimer. Maxtimer 185 specifies the maximum amount of time in integer seconds the 186 client will wait for a response from the server before assuming 187 the server is not available. 188 7. This service extension is appropriate for the standard SMTP 189 [RFC2821], SMTP submission protocol [RFC2476] and LMTP [RFC2033]. 191 3.2 Extension Operation 193 3.2.1 Server Behavior 195 Upon receiving a RDLV verb, the server examines the maxtimer 196 parameter. If maxtimer is less than mintimer, the server SHOULD 197 respond with a 501 (5.5.4 Bad Parameter). The server MAY elect to 198 honor the shorter timer. However, especially under load, the server 199 should not accept undue burdens from clients. 201 If there is no maxtimer parameter, the server MUST respond with a 501 202 (5.5.2 Missing parameter). 204 If the maxtimer parameter is acceptable, the server MUST respond with 205 a 250 response code and set the server's state to issue 120 responses 206 to the following long command, at least every maxtimer seconds. 208 If, when the client issues the next command, the server determines it 209 is not able to issue 120 responses to the particular command, the 210 server MUST respond with a 520 (5.3.3 System not capable of selected 211 features [Is this correct?]) response code. The server MUST 212 terminate both the RDLV and the last received command request. 214 The server MUST set its interval timer to something less than 215 maxtimer to ensure that the time from the client's perspective, 216 including transit delays, is less than maxtimer. A reasonable amount 217 of time to reduce maxtimer is 7 seconds. 219 If the server receives a EHLO, HELO, or RSET, it MUST clear the 220 server's state, including terminating the sending 120 responses. 222 If the server completes processing the long command, the server 223 responds to the client with the appropriate response code. If the 224 server has not completed processing in maxtimer seconds since the 225 last response, the server MUST issue a 120 response. 227 When the server issues the 120 response, the server waits for the 228 client to issue a CONT request. The server SHOULD continue 229 processing while waiting for the CONT request. 231 When the server receives the CONT request, the server MUST continue 232 processing, and the server MUST issue another 120 response (now to 233 the CONT request) within maxtimer seconds. 235 If the server does not receive a CONT request within maxtimer 236 seconds, the server MUST consider the client gone. 238 After the long transaction completes or the client abandons the 239 transaction, the server MUST set its state to not issue 120 240 responses, unless requested again by a new RDLV request. 242 3.2.2 Client Behavior 244 To receive notifications from the server that the server is still 245 working on a long transaction, the client MUST issue a RDLV request 246 before the long transaction request, such as DATA, BDAT, or BURL. 247 The RDLV request MUST have a maxtimer parameter indicating the 248 maximum number of seconds the server can wait before issuing a 120 249 request. Maxtimer MUST NOT be less than the mintimer parameter 250 issued by the server in the EHLO keyword. 252 The client then issues the long transaction request as normal. The 253 server will respond with the normal result code for the request or a 254 120 response. 256 To continue the long transaction, the client MUST issue a CONT 257 request. Issuing other requests, or ignoring the 120 response, is 258 not defined, except for the client issuing a new EHLO, HELO, or RSET 259 requests. Those requests reset the state of the server, as specified 260 in SMTP [RFC2821]. 262 The client MUST wait a reasonable amount of time, in addition to 263 maxtimer seconds, for the 120 response. This is to account for 264 congested transit delays between the client and server. A reasonable 265 amount of time to wait before abandoning the transaction is 7 266 seconds. 268 Server generation of 120 responses is per-transaction. Thus, if the 269 client wishes to receive 120 responses on a new long request, the 270 client MUST issue a new RDLV request before issuing the long 271 transaction request. 273 If the server is unable to comply with the RDLV request for a 274 particular verb, the server will respond with a 520 (5.3.3 System not 275 capable of selected features) response code to the verb. In this 276 case the server has rejected both the RDLV and the verb request. The 277 client is free to make the verb request again without preceding it 278 with a RDLV request. 280 If the server also supports PIPELINING [RFC3030] SMTP extension, then 281 the RDLV command MUST be the last command in a group of pipelined 282 commands. 284 4. Formal Syntax 286 Formal syntax is defined using ABNF [ABNF]. Elements not defined 287 here can be found in the [ABNF] and SMTP [RFC2821]. 289 seconds = 1*DIGIT 290 ; 31-bit positive integer 291 ; (1 <= n < 2,147,483,648) 293 rdlv-param = "mintimer" "=" seconds 294 ; parameter to RDLV EHLO keyword. 295 ; matches "ehlo-keyword" 297 rdlv-cmd = "RDLV" SP "maxtimer" "=" seconds CRLF 299 cont-cmd = "CONT" 301 5. IANA Considerations 303 Please register the RDLV service extension in the Simple Mail 304 Transfer Protocol (SMTP) Service Extensions table as follows. 306 Service Extension 307 Keyword: RDLV 308 Description: Reliable Delivery 309 Reference: RFCXXXX 311 Service Extension Parameters 312 Service Extension: Reliable Delivery 313 EHLO Keyword: RDLV 314 Parameters: maxtimer 315 Reference: RFCXXXX 317 6. Examples 319 These examples are informative in nature. For any discrepancies 320 between behavior here and the normative behavior, the normative 321 behavior is correct. 323 6.1 Long Submit 325 This addresses the classic long submit problem. The client sets the 326 RDLV to 600 seconds, the classic 10-minute timeout. Rather than 327 giving up at 10 minutes, the client watches for the 120. Upon 328 receiving the 120, it knows the server is still alive. The client 329 requests a continuation of the request, and after 22 minutes, the 330 submission succeeds. Compare that to the classic way, where the 331 submission would fail. 333 S: 220 example.net SMTP XYZ Ready 334 C: EHLO example.com 335 S: 250-example.net greets example.com 336 S: 250-8BITMIME 337 S: 250-BURL imap 338 S: 250-RDLV mintimer=30 339 S: 250-DSN 340 S: 250 HELP 341 C: MAIL FROM: 342 S: 250 OK 343 C: RCPT TO: 344 S: 250 OK 345 C: RDLV maxtimer=600 346 S: 200 OK 347 C: DATA 348 S: 354 Start mail input; end with . 349 C: [... lots and lots of data ...] 350 C: 351 C: . 352 [about 10 minutes pass] 353 S: 120 DATA processing in progress 354 C: CONT 355 [about 10 minutes pass] 356 S: 120 DATA processing in progress 357 C: CONT 358 [about 2 minutes pass] 359 S: 250 OK 360 C: QUIT 361 S: 221 example.net Service closing transmission channel 363 6.2 Unsupported Verb 365 The client requests in-process notifications for a method that the 366 server does not support in-process notifications for the following 367 verb, BURL in this case. 369 S: 220 example.net SMTP XYZ Ready 370 C: EHLO example.com 371 S: 250-example.net greets example.com 372 S: 250-8BITMIME 373 S: 250-BURL imap 374 S: 250-RDLV mintimer=30 375 S: 250-DSN 376 S: 250-ENHANCEDSTATUSCODES 377 S: 250 HELP 378 C: MAIL FROM: 379 S: 250 2.5.0 OK 380 C: RCPT TO: 381 S: 250 2.1.5 OK 382 C: RDLV maxtimer=600 383 S: 200 2.5.0 OK 384 C: BURL imap://handset@host.example.com/outbox 385 ;uidvalidity=a9j230r932/;uid=32 386 ;authid=fred;urlauth=submit+handset 387 :internal:91354a473744909de610943775f92038 LAST 388 S: 520 5.3.3 This server does not support RDLV for BURL 389 C: QUIT 390 S: 221 2.0.0 example.net Service closing transmission channel 392 6.3 Remote Submit 394 This addresses the problem raised by the Lemonade WG. The client 395 issues a very small request, a BURL. However, the object referenced 396 by the BURL is quite large. The client sets the RDLV to 60 seconds, 397 so it keeps aware of the progress of message. 399 S: 220 example.net SMTP XYZ Ready 400 C: EHLO example.com 401 S: 250-example.net greets example.com 402 S: 250-8BITMIME 403 S: 250-BURL imap 404 S: 250-RDLV mintimer=30 405 S: 250-DSN 406 S: 250 HELP 407 C: MAIL FROM: 408 S: 250 OK 409 C: RCPT TO: 410 S: 250 OK 411 C: RDLV maxtimer=60 412 S: 200 OK 413 C: BURL imap://handset@host.example.com/outbox 414 ;uidvalidity=a9j230r932/;uid=32 415 ;authid=fred;urlauth=submit+handset 416 :internal:91354a473744909de610943775f92038 LAST 417 [about a minute passes] 418 S: 120 DATA processing in progress 419 C: CONT 420 [about a minute passes] 421 S: 120 DATA processing in progress 422 C: CONT 423 [about a minute passes] 424 S: 120 DATA processing in progress 425 C: CONT 426 [about a minute passes] 427 S: 120 DATA processing in progress 428 C: CONT 429 S: 250 OK 430 C: QUIT 431 S: 221 example.net Service closing transmission channel 433 7. Security Considerations 435 Malicious clients can amplify server load by issuing unreasonably 436 high notification rates in addition to sending large, complex 437 documents. Servers MUST ensure to deny client requests for unduly 438 short inter-notification times. 440 8. References 442 8.1 Normative References 444 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 445 Specifications: ABNF", RFC 2234, November 1997. 447 [PIPELINING] 448 Freed, N., "SMTP Service Extension for Command 449 Pipelining", STD 60, RFC 2920, September 2000. 451 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 452 October 1996. 454 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 455 Error Codes", RFC 2034, October 1996. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 461 RFC 2476, December 1998. 463 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 464 April 2001. 466 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 467 RFC 3464, January 2003. 469 8.2 Informative References 471 [RFC1047] Partridge, C., "Duplicate messages and SMTP", RFC 1047, 472 February 1988. 474 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 475 and Support", STD 3, RFC 1123, October 1989. 477 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 478 of Large and Binary MIME Messages", RFC 3030, 479 December 2000. 481 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 482 for Delivery Status Notifications", RFC 3464, 483 January 2003. 485 [burl] Newman, C., "Message Submission BURL Extension", Internet 486 Draft draft-ietf-lemonade-burl-00.txt, July 2004. 488 Authors' Addresses 490 Eric Burger 491 Brooktrout Technology, Inc. 492 18 Keewaydin Dr. 493 Salem, NH 03079 494 USA 496 Email: e.burger@ieee.org 498 Alexey Melnikov 499 Isode Ltd. 500 5 Castle Business Village 501 36 Station Road 502 Hampton, Middlesex TW12 2BX 503 GB 505 Email: alexey.melnikov@isode.com 507 Appendix A. Acknowledgements 509 The need for notification that the SMTP server is still doing work 510 came from the lemonade interim meeting in May of 2004 in Richardson, 511 TX, USA. 513 Intellectual Property Statement 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed to 517 pertain to the implementation or use of the technology described in 518 this document or the extent to which any license under such rights 519 might or might not be available; nor does it represent that it has 520 made any independent effort to identify any such rights. Information 521 on the procedures with respect to rights in RFC documents can be 522 found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use of 527 such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository at 529 http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at 535 ietf-ipr@ietf.org. 537 The IETF has been notified of intellectual property rights claimed in 538 regard to some or all of the specification contained in this 539 document. For more information consult the online list of claimed 540 rights. 542 Disclaimer of Validity 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Copyright Statement 554 Copyright (C) The Internet Society (2005). This document is subject 555 to the rights, licenses and restrictions contained in BCP 78, and 556 except as set forth therein, the authors retain all their rights. 558 Acknowledgment 560 Funding for the RFC Editor function is currently provided by the 561 Internet Society.