idnits 2.17.1 draft-vaudreuil-futuredelivery-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 463. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 24 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 169: '... use Future Message Release MUST first...' RFC 2119 keyword, line 172: '... Message Release MUST include one, and...' RFC 2119 keyword, line 176: '...of the hold-param MUST ensure that the...' RFC 2119 keyword, line 181: '...of the hold-param MUST ensure that the...' RFC 2119 keyword, line 187: '... Message Release MUST comply with the ...' (28 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3463, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3464, 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 (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 (August 10, 2006) is 6462 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT G. White 2 draft-vaudreuil-futuredelivery-04.txt Independent 3 Updates: RFC 3463, 3464 G. Vaudreuil 4 Expires: February 10, 2006 Lucent Technologies 5 August 10, 2006 7 SMTP Submission Service Extension for Future Message Release 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This memo defines an extension to the SMTP submission protocol for a 36 client to indicate a future time for the message to be released for 37 delivery. This extension permits a client to use server-based 38 storage for a message that should be held in queue until an 39 appointed time in the future. This is useful for clients which do 40 not have local storage or are otherwise unable to release a message 41 for delivery at an appointed time. 43 1. Introduction 45 There is a widely-used feature within the voice messaging community 46 to compose and send a message for delivery in the future. This is 47 useful for sending announcements to be heard at the beginning of a 48 work day, to send birthday greetings a day or so ahead, or to use as 49 a lightweight facility to build a personal reminder service. 51 This extension uses the SMTP submission protocol [n3] to allow a 52 client, when submitting a message, to indicate a future time for the 53 message to be released for delivery. 55 2. Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [n1]. 61 3. Framework 63 The Future Message Release service extension for SMTP submission uses 64 the SMTP service extension mechanism [n4] to extend the SMTP 65 submission protocol [n3]. The following SMTP submission service 66 extension is hereby defined: 68 The name of the SMTP submission service extension is "Future Message 69 Release". 71 1) The EHLO keyword associated with this service extension is 72 "FUTURERELEASE". 74 2) Two required parameters, the max-future-release-interval and the 75 max-future-release-date-time, are combined with the EHLO keyword 76 in the manner specified in [n4]. 78 The max-future-release-interval is a positive integer indicating 79 the maximum amount of time for which the message submission server 80 (MSA) will hold messages for future release. 82 Using ABNF [n2], the syntax of this parameter is as follows: 84 future-release-integer = %x31-39 *8DIGIT 85 ; integer in the range 1-999999999 86 ; measured in seconds 88 max-future-release-interval = future-release-integer 90 The max-future-release-date-time is a timestamp, normalized to 91 Universal Coordinated Time (UTC), indicating the most remote date 92 and time in the future until which the MSA will hold messages for 93 future release. 95 Using ABNF [n2], the syntax of this parameter is as follows: 97 max-future-release-date-time = date-time 99 where the format of date-time is defined in [n10]. 101 3) When forming the portion of the EHLO reply containing the 102 FUTURERELEASE keyword, the keyword is followed by the 103 max-future-release-interval, and then the 104 max-future-release-date-time. The keyword and two values are 105 delimited by spaces. 107 For example, the ABNF for a continuation line in the EHLO response 108 that contains the FUTURERELEASE keyword is: 110 line = "250-FUTURERELEASE" SP max-future-delivery-interval 111 SP max-future-delivery-date-time 113 4) One required parameter, the hold-param, is added to the MAIL 114 command using either the keyword "HOLDFOR" or the keyword 115 "HOLDUNTIL". 117 The HOLDFOR parameter value is a future-release-interval, 118 which is a positive integer indicating the amount of time the 119 message is to be held by the MSA before release. 121 The HOLDUNTIL parameter value is a future-release-date-time, 122 which is a timestamp, normalized to UTC, indicating the future 123 date and time until which the message is to be held by the MSA 124 before release. 126 Using ABNF [n2], the syntax of this parameter is as follows: 128 future-release-interval = future-release-integer 130 future-release-date-time = Internet-style-date-time-UTC 132 hold-for-param = "HOLDFOR=" future-release-interval 134 hold-until-param = "HOLDUNTIL=" future-release-date-time 136 hold-param = hold-for-param / hold-until-param 138 The absence of this parameter on the MAIL command does not imply a 139 default value for this parameter. 141 5) The maximum length of a MAIL command is increased by 34 characters 142 by the possible addition of the hold-param. 144 6) No additional SMTP verbs are defined by this extension. 146 7) This service extension is appropriate only for the SMTP 147 submission protocol [n3]. This service extension is not 148 appropriate for standard SMTP [n4]. 150 4.1 Behavior 152 It is unfortunate to define two seemingly identical ways to indicate 153 a future delivery time. When the client has both accurate time and 154 accurate time zone information, either interval or date-time can be 155 trivally calculated from the other. However, in the current world of 156 clients, there are clients with accurate local time but no indication 157 of their time zone, and client without a suitably accurate clock. 158 Based on the limited facilities available to these time-challenged 159 clients, it is likely that only one or the other of these mechanisms 160 will be useful. 162 It is believed that servers will have accurate time, and can trivally 163 convert between these mechanisms. It is also accepted that the 164 protocol and implementation overhead of offering these two mechanisms 165 is low, and that few interoperability challenges are anticipated. 167 4.1.1 SMTP client behavior 169 1) An SMTP client preparing to use Future Message Release MUST first 170 verify that the MSA supports this extension. 172 2) An SMTP client using Future Message Release MUST include one, and 173 only one, hold-param with the MAIL command. 175 4) An SMTP client using Future Message Release with the "for" 176 option of the hold-param MUST ensure that the 177 future-release-interval is less than or equal to the 178 max-future-release-interval advertised by the MSA. 180 4) An SMTP client using Future Message Release with the "until" 181 option of the hold-param MUST ensure that the 182 future-release-date-time is earlier than or equal to the 183 max-future-release-date-time advertised by the MSA. 185 4.1.2 MSA behavior 187 1) An MSA supporting Future Message Release MUST comply with the SMTP 188 submission protocol as described in [n3]. 190 2) An MSA supporting Future Message Release MUST NOT advertise this 191 support (i.e. include the FUTURERELEASE keyword in its EHLO reply) 192 on any port other than the submission port. 194 3) An MSA supporting Future Message Release MUST include the 195 FUTURERELEASE keyword, and associated max-future-release-interval 196 and max-future-release-date-time parameters, in its reply to the 197 EHLO command. 199 4) An MSA supporting Future Message Release MUST accept a MAIL 200 command containing a valid hold-param, given that the MAIL command 201 contains no other errors. 203 5) An MSA that accepts a message with a request for Future Message 204 Release indicating the "for" option MUST NOT release the message 205 until the amount of time specified in the future-release-interval 206 elapses. 208 6) An MSA that accepts a message with a request for Future Message 209 Release indicating the "until" option MUST NOT release the message 210 until the date and time indicated by the future-release-date-time 211 occurs. 213 7) An MSA supporting Future Message Release MUST reject a MAIL 214 command containing the "for" option specifying a value that is 215 greater than the advertised max-future-release-interval, or 216 otherwise invalid. 218 8) An MSA supporting Future Message Release MUST reject a MAIL 219 command containing the "until" option specifying a value that 220 is later than the advertised max-future-release-date-time, or 221 otherwise invalid. 223 9) An MSA supporting Future Message Release MUST reject a MAIL 224 command containing more than one hold-param. 226 10) An MSA supporting Future Message Release, when rejecting a MAIL 227 command per 4.1.2.7, 4.1.2.8 or 4.1.2.9, SHOULD supply the reply 228 code 501 (syntax error in parameters or arguments [n4]) in 229 the reply. 231 11) An MSA supporting Future Message Release, when rejecting a MAIL 232 command per 4.1.2.7, 4.1.2.8 or 4.1.2.9, SHOULD supply the 233 Enhanced Mail System Status Code 5.5.4 (invalid command 234 arguments [i1]) in the reply. 236 4.2 Interaction with the DSN SMTP service extension 238 The Delivery Status Notification (DSN) service extension is described 239 in [n7], and DSN message format is described in [n8]. 241 4.2.1 SMTP client interaction with DSN 243 1) An SMTP client MUST NOT request Future Message Release when 244 sending a DSN to the MSA. 246 4.2.2 MSA interaction with DSN 248 1) If an MSA generates a DSN for a message that includes a Future 249 Message Release request, the MSA MUST include an Arrival-Date: 250 field in the machine-readable body part of the DSN. 252 2) If an MSA generates a DSN for a message that includes a Future 253 Message Release request, the MSA MUST include a 254 Future-Release-Request: field in the machine-readable body 255 part of the DSN. The value of this field is the value of the HOLD 256 parameter contained in the MAIL command of the original message. 258 The Future-Release-Request: field is an extension to the 259 set of DSN per-message fields described in [n8]. Using ABNF [n2], 260 the syntax of this new field is as follows: 262 orig-hold-param-value = ("for;" future-release-interval) / 263 ("until;" future-release-date-time) 264 ; this is the value of the HOLD parm from 265 ; the MAIL command of the original message 267 future-release-request-field = "Future-Release-Request:" 268 orig-hold-param-value 270 4.3 Interaction with the DELIVERBY SMTP service extension 272 If an MSA supports the Future Message release and Deliver By service 273 extensions, it is possible for an SMTP client to make simultaneous 274 requests for future message release and deliver-by times when 275 submitting a message. A problem will occur if the future message 276 release time is farther in the future than the deliver-by time. In 277 order to honor the deliver-by request, the future message release 278 request has to be ignored. In order to honor the future message 279 release request, the deliver-by request has to be ignored. This 280 section addresses that problem. The Deliver By extension is 281 described in [n6]. 283 4.3.1 SMTP client interaction with DELIVERBY 285 1) When an SMTP client wishes to use the Future Message Release and 286 Deliver By extensions with the same message, the client MUST 287 ensure that the specified deliver-by time is farther in the 288 future than the specified ("until" option) or implied ("for" 289 option) future message release time. 291 4.3.2 MSA interaction with DELIVERBY 293 1) If an MSA supports Future Message Release and Deliver By 294 extensions, and receives a message requesting the use of both 295 extensions, the MSA MUST reject the MAIL command if it determines 296 that the future message release time is farther in the future than 297 the deliver-by time. 299 2) When an MSA is rejecting a MAIL command per 4.3.2.1, it SHOULD 300 supply the reply code 501 (syntax error in parameters or arguments 301 [n4]) in the reply. 303 3) When an MSA is rejecting a MAIL command per 4.3.2.1, it SHOULD 304 supply the Enhanced Mail System Status Code 5.5.4 (invalid 305 command arguments [i1]) in the reply. 307 4.4 Interaction with the MDN function 309 The Message Disposition Notification (MDN) function is described in 310 [n9]. 312 4.4.1 SMTP client interaction with MDN 314 1) An SMTP client MUST NOT request Future Message Release when 315 sending an MDN to the MSA. 317 5. Security Considerations 319 The Future Message Release service extension presents a number of 320 security considerations: 322 1) Unauthorized future-release messages provide a means to 323 overwhelm the storage of an MSA. The authorization mechanisms 324 required for the base mail submission protocol [n3] are expected 325 to provide appropriate defense against such attacks. 327 2) Authorized future-message-release without a per-user quota may 328 also provide a way to overwhelm an MSA's storage. An MSA's 329 future-release message storage SHOULD be subject to a per-user 330 quota. 332 3) If an MSA is imposing a per-user quota on future-release message 333 storage, and detects that an incoming future-release message will 334 exceed the user's future-release message storage quota, the MSA 335 MUST reject the MAIL command. 337 4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply 338 the reply code 552 (requested mail action aborted: exceeded 339 storage allocation [n4]) in the reply. 341 5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply 342 the new Enhanced Mail System Status Code defined for this purpose. 343 This new status code updates [i1]. 345 X.7.9 Future-release per-user message quota exceeded 347 There is insuffient per-user quota to queue the message for 348 future release. This code suggests the client can 349 submit again only after the per-user queue has drained. 351 X.7.10 Future-release system message quota exceeded 353 There is insuffient system quota to queue the message for 354 future release. This code suggests the client can 355 submit again after the system queue has drained. 357 6) Inaccurate time on the MSA may result in premature or delayed release 358 of messages. Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive 359 to inaccurate or changing clocks on the MSA. 361 7) Some element of deception is inherent in the future message 362 release concept. The message release time is intentionally 363 delayed past the time it would otherwise be released; hence, 364 the message delivery time is delayed past the time it would 365 otherwise be delivered. This extension provides no mechanism for 366 hiding this from the message recipient. The RFC 2822 message 367 header, and specifically the Date: field, remain unchanged after 368 submission. While a sending client MAY elect to place the 369 future-message-release-time as the date in the Date: field, there 370 is no requirement or expectation that the Received: fields and 371 other trace information be modified by the transport system to 372 further this deception. 374 6. IANA Considerations 376 According to the IANA website, this extension will be added to the 377 list of SMTP extensions on the Mail Parameters web page. 379 7. Acknowledgments 381 Much of credit for this draft is due to the LEMONADE working group. 382 Through many revisions the discussion resulted in fundamental new 383 understandings of this protocol and corresponding refinement of 384 the implied requirements and protocol. Special thanks to those who 385 patiently lead the WG to understand that doing both interval and 386 date-time was the pragmatically correct approach to the needs of diverse 387 clients. 389 8. Normative References 391 [n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 392 Levels", BCP 14, RFC 2119, March 1997. 394 [n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 395 Specifications: ABNF", RFC 4234, October 2005. 397 [n3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, 398 December 1998. 400 [n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 401 2001. 403 [n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 405 [n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 406 2000. 408 [n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 409 Extension for Delivery Status Notifications (DSNs)", RFC 3461, 410 January 2003. 412 [n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 413 Delivery Status Notifications", RFC 3464, January 2003. 415 [n9] Hansen, T. and G. Vaudreuil, "Message Disposition 416 Notification," RFC 3798, May 2004. 418 [n10] Klyne, G. and C. Newman, "Date and Time on the Internet: 419 Timestamps," RFC 3339, July 2002 421 9. Informative References 423 [i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, 424 January 2003. 426 10. Authors' Addresses 428 Gregory A. White 429 6519 Camille Ave. 430 Dallas, TX 75252 431 USA 432 E-Mail: g.a.white@comcast.net 434 Gregory M. Vaudreuil 435 Lucent Technologies 436 9489 Bartgis Ct 437 Frederick, MD 21702 438 USA 439 E-Mail: GregV@ieee.org 441 11. Intellectual Property Rights Notice 443 The IETF takes no position regarding the validity or scope of any 444 Intellectual Property Rights or other rights that might be claimed 445 to pertain to the implementation or use of the technology described 446 in this document or the extent to which any license under such rights 447 might or might not be available; nor does it represent that it has 448 made any independent effort to identify any such rights. Information 449 on the procedures with respect to rights in RFC documents can be 450 found in BCP 78 and BCP 79. 452 Copies of IPR disclosures made to the IETF Secretariat and any 453 assurances of licenses to be made available, or the result of an 454 attempt made to obtain a general license or permission for the use 455 of such proprietary rights by implementers or users of this 456 specification can be obtained from the IETF on-line IPR repository 457 at http://www.ietf.org/ipr. 459 The IETF invites any interested party to bring to its attention any 460 copyrights, patents or patent applications, or other proprietary 461 rights that may cover technology that may be required to implement 462 this standard. Please address the information to the IETF at 463 ietf-ipr@ietf.org. 465 12. Copyright Notice and Disclaimer 467 Copyright (C) The Internet Society (2006). 469 This document is subject to the rights, licenses and restrictions 470 contained in BCP 78, and except as set forth therein, the authors 471 retain all their rights. 473 This document and the information contained herein are provided on an 474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 476 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 477 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 478 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 13. Change Log (to be removed upon RFC Publication) 483 13.0 Changes from -03 to -03.txt 485 1) Numerous editorial fixes 487 2) New status code for system quota exceeded 489 3) Rework to correct BNF for max-future-release-date-time 491 4) Augmented security considerations to address server time inaccuracy 493 13.1 Changes from draft-ietf-lemonade-futuredelivery-04.txt to draft-vaudreuil-futuredelivery-03 495 1) Changed filename back to non-WG form to reflect consensus that this be 496 progressed as an individual contribution. 498 13.2 Changes from -03.txt to -04.txt 500 1) Changed extension framework to define HOLDFOR and HOLDUNTIL for 501 the MAIL command (instead of the HOLD parameter). 503 2) Made wording changes to several of the SMTP client and MSA 504 behavior requirements 506 13.3 Changes from -02.txt to -03.txt 508 1) Rewrote entire draft in terms of future message release instead of 509 future message delivery. Almost every paragraph of Sections 1 510 through 5 have been changed. 512 13.4 Changes from -01.txt to -02.txt 514 1) Clarified requirements in section 4.1.1, SMTP client behaviour. 516 2) Removed the requirement that the MSA comply with the SMTP service 517 extension mechanism, as the list thought this was redundant text. 519 3) Added requirement that the MSA MUST only advertise this extension 520 on the submission port. 522 4) Added requirements stating how to form the reply to a MAIL command 523 when the future delivery time included with the MAIL command is 524 greater than the max-allowable-future-delivery-time advertised by 525 the MSA. 527 5) Added requirements stating how to form the reply to a MAIL command 528 when the future-delivery-time and the deliver-by time don't align 529 properly. 531 6) Change the level of the requirement of the per-user quota 532 requirement in Section 5, Security Considerations, from "highly 533 RECOMMENDED" to "SHOULD". 535 7) Added requirements stating how to form the reply to a MAIL command 536 when the MSA detects that the future delivery message will exceed 537 the user's future delivery quota. This includes the definition of 538 a new Enhanced Mail System Status Code. 540 13.5 Changes from -00.txt to -01.txt 542 1) Removed the Mechanism section, as it pretty much duplicated the 543 Behavior section. 545 2) Removed the requirement that an MSA supporting FUTUREDELIVERY MUST 546 also support the AUTH extension. Removed all of the requirements 547 referencing the AUTH extension. 549 3) Changed requirement for EHLO FUTUREDELIVERY keyword so that a 550 positive max-future-delivery-interval value MUST be supplied with 551 that keyword. A value of zero, or no value at all, are no longer 552 options. 554 4) Changed the ABNF definition of max-future-delivery-interval and 555 future-delivery-interval from [1*9DIGIT] to [%x31-39 *8DIGIT]. 556 This change forces these values to be integers in the range 557 1-999999999. 559 5) Added section for FUTUREDELIVERY interaction with MDN. 561 6) Modified the definition of the Future-Delivery-Date: field to 562 state that the zone in the date-time value MUST be numeric. Since 563 this field goes in the machine-readable portion of a DSN, this 564 change was made so the definition matches the definitions of the 565 other date fields defined in RFC 3464. 567 7) Rewrote Security Considerations in terms of "authorization" 568 instead of "authentication." 570 8) Modified paragraph 1) of Security Considerations to state that an 571 MSA supporting FUTUREDELIVERY MUST employ at least one of the 572 authorization mechanisms listed in RFC 2476. 574 9) Made all (hopefully) of the changes necessary for the draft to be 575 compliant with ID-NITS and ID-GUIDELINES found on the IETF 576 website. Made other wordsmithing changes to improve clarity. 578 13.6 Discussion of -00.txt 580 As a note, the -00.txt version of this draft was previously published 581 as draft-vaudreuil-futuredelivery-02.txt. The name of the draft was 582 changed after the LEMONADE WG voted to make this document a WG item.