idnits 2.17.1 draft-ietf-fax-timely-delivery-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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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. RFC 2119 keyword, line 337: '...which timely delivery is required MUST...' RFC 2119 keyword, line 355: '... The message MUST NOT be transmitted ...' RFC 2119 keyword, line 357: '...a negative delivery status report MUST...' RFC 2119 keyword, line 364: '...e for timely delivery MUST support all...' RFC 2119 keyword, line 381: '... MUST NOT be relayed. Instead, a neg...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 381 has weird spacing: '...egative deliv...' == Line 430 has weird spacing: '... should ensur...' -- 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 (13 September 2000) is 8624 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: '1' is defined on line 585, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 615, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2542 (ref. '1') ** Obsolete normative reference: RFC 821 (ref. '2') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1651 (ref. '3') (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 1891 (ref. '4') (Obsoleted by RFC 3461) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Unknown state RFC: RFC 1047 (ref. '9') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF fax WG G. Klyne, Content Technologies 3 Internet draft [[[et al]]] 4 13 September 2000 5 Expires: March 2001 7 Timely Delivery for Internet Messaging Services 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 35 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 36 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 37 West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society 2000. All Rights Reserved. 43 Abstract 45 This proposal describes a way to request timely delivery for 46 facsimile, voice and other messaging services that use Internet 47 e-mail. It provides a deterministic service quality response, 48 while preserving the traditional roles and responsibiltiies of the 49 agents involved in e-mail transfers. 51 It is essentially a profile of the DSN and DELIVERBY extentions for 52 ESMTP, and a new COMPLIANCE extension for establishing the 53 deterministic service quality response. 55 Content Negotiation for Internet Fax 13 September 56 58 NOTE: This is an early, preliminary version of specification, 59 indicating a possible way to achieve the timely delivery 60 requirement for full mode Internet fax. The content is rough, and 61 the intent at this time is to indicate the outline of a mechanism. 62 Please address comments to major structural and semantic issues. 64 Discussion of this document 66 Please send comments to: . 68 To subscribe: send a message with the body 'subscribe' to . 71 The mailing list archive is at: . 73 Table of contents 75 1. Introduction.............................................3 76 1.1 Structure of this document ...........................3 77 1.2 Document terminology and conventions .................3 78 2. Background and goals.....................................3 79 2.1 Background ...........................................3 80 2.2 Basis for timely delivery ............................4 81 2.2.1 The SMTP "contract"..............................4 82 2.2.2 Framework for timely delivery....................5 83 2.3 Why is 'compliance required' included? ...............6 84 2.4 Goals for timely delivery ............................6 85 3. Mechanisms for timely delivery...........................7 86 3.1 Transmitting a message for timely delivery ...........7 87 3.2 Relaying a message ...................................8 88 3.3 Accepting a message by the final MTA .................9 89 3.4 Timely confirmation ..................................10 90 4. Compliance-required ESMTP extension......................11 91 5. DSN reporting extensions.................................11 92 6. Notes....................................................11 93 7. Examples.................................................12 94 8. IANA Considerations......................................12 95 9. Internationalization considerations......................12 96 10. Security considerations.................................12 97 11. Acknowledgements........................................12 98 12. References..............................................12 99 13. Authors' addresses......................................13 100 Appendix A: Amendment history...............................14 101 Full copyright statement....................................14 102 Content Negotiation for Internet Fax 13 September 103 105 1. Introduction 107 1.1 Structure of this document 109 [[[TBD]]] 111 1.2 Document terminology and conventions 113 [[[TBD]]] 115 NOTE: Comments like this provide additional nonessential 116 information about the rationale behind this document. 117 Such information is not needed for building a conformant 118 implementation, but may help those who wish to understand 119 the design in greater depth. 121 [[[Editorial comments and questions about outstanding issues are 122 provided in triple brackets like this. These working comments 123 should be resolved and removed prior to final publication.]]] 125 2. Background and goals 127 RFC 2852 [5] provides a mechanism to request timely delivery of a 128 message using SMTP. While this is helpful, it falls short of the 129 goals for timely delivery of fax messages. These goals are 130 determined, in part, by the capabilities of traditional facsimile 131 [8]. 133 2.1 Background 135 Traditional e-mail [2] is open-loop. The sender of a message 136 normally has no certainty if or when a message is delivered. (A 137 separate memo [6] contains a discussion of some open- and closed- 138 loop issues in e-mail.) 140 To be more than just a hint to the message transfer system, timely 141 delivery requires a deterministic confirmation mechanism, to close 142 the loop. This is provided by DSN [4]. 144 Three kinds of timeliness can be identified: 146 (a) timely delivery to the receipient 148 (b) timely notification to the sender of delivery 150 (c) timely notification to the sender that the message has been 151 received and processed 152 Content Negotiation for Internet Fax 13 September 153 155 From the sender's point of view, timely confirmation of receipt and 156 processing is the most desirable requirement. 158 2.2 Basis for timely delivery 160 A key premise of this proposal is that timeliness CAN be achieved 161 using existing protocols, with appropriate software design and 162 operational management. BUT the sender and receiver do not control 163 all the relays used: 165 o The real issue is lack of determinism: a message might be 166 delivered quickly, or it might take hours or even days, or it 167 might not be delivered at all; the sender has little knowledge 168 and no control. 170 o A secondary issue is post-delivery handling: will the receiving 171 user agent process the message in timely fashion? 173 One challenge to achieving this is dealing with uncertain transit 174 times of the confirmation message over the return path (which is 175 not necessarily the same as the forward path). 177 2.2.1 The SMTP "contract" 179 On accepting a message, a normal SMTP message transfer agent (MTA) 180 accepts responsibility to: 182 (a) use best efforts to ensure delivery of the message, or 184 (b) provide notification that delivery could not be achieved. 186 This memo introduces mechanisms to allow this contract to be 187 modified. A timely-delivery MTA accepts responsibility to: 189 (a) use reasonable efforts to ensure delivery within a specified 190 time, and to provide timely confirmation of delivery, or 192 (b) provide timely notification that delivery was not achieved. 194 The sender can then decide a recovery strategy 195 Content Negotiation for Internet Fax 13 September 196 198 2.2.2 Framework for timely delivery 200 The diagram shows typical SMTP message delivery and delivery status 201 notification (DSN) paths. Note that the confirmation path is not 202 necessarily the same as the message delivery path. 204 Outbound message --> 206 +-------+ +-----+ +-----+ +---------+ 207 |Sending|-->--|Relay| >>> |Relay|-->--|Receiving| 208 | MTA | | MTA | | MTA | | MTA | 209 +-------+ +-----+ +-----+ +---------+ 210 | | | 211 ^ | v 212 | | | 213 +-------+ | +---------+ 214 |Sending| | |Receiving| 215 | UA |-<------------- <<< ------------- | UA | 216 +-------+ +---------+ 217 <-- Return confirmation 219 As well as requesting timely delivery of a message, this proposal 220 needs to take account of the possibly varying characteristics of 221 relays of the outbound and return message paths. Practically, it 222 is possible to require that every relay on the outbound path 223 recognizes timely delivery semantics (using the ESMTP extension 224 framework), but it is not possible to require this of every relay 225 on the return path. Thus, it may be necessary to make some 226 assumptions about the confirmation return path. 228 NOTE: The uncertainty about return path characteristics 229 might be removed by requiring an MTA to send any timely 230 delivery notifcation to the MTA from which it was 231 received, but this goes against trends in SMTP design and 232 deployment. This might also raise state maintenance and 233 hence scalability concerns. 235 The other issue apparent from the diagram is that providing timely 236 delivery through the SMTP message relays does not ensure that the 237 receiving MTA will process the message in a timely fashion. If the 238 receiving MTA delivers to a POP mailbox, thereis no way that it can 239 guarantee timely delivery. 241 Content Negotiation for Internet Fax 13 September 242 244 2.3 Why is 'compliance required' included? 246 For the purposes of SMTP transfer, the "compliance required" 247 feature is not required and there is a strong case for pursuing 248 timely delivery without that part. 250 But consider the following scenario: 252 +--------+ +-------+ +-----------+ +-----------+ 253 | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing | 254 | MTA | | MTA | | MTA | | agent | 255 +--------+ +-------+ +-----------+ +-----------+ 257 <------SMTP-------> <-?-> 259 The DELIVER-BY specification concerns itself only with the SMTP 260 transfers. But for the purposes of timely delivery, the goal is 261 not satisfied from a user perspective unless the disposition also 262 completes in "timely" fashion. 264 The "compliance required" option expects that the receiving MTA 265 communicates with the disposing agent (in some unspecified way), 266 and confirms final delivery of the message only if the disposing 267 agent confirms that it will deal with the message in timely 268 fashion. Simply putting the message into a POP mailbox would not 269 meet this criterion. It also permits an MTA to commute its 270 responsibility for delivering the message from "best effort" to 271 "reasonable effort". 273 This is all consistent with the fundamental strategy of giving the 274 sender control over the whole process: if the disposing agent 275 cannot communicate the required guarantee, delivery is not 276 completed and the sender is duly notified. 278 2.4 Goals for timely delivery 280 The primary goal is to provide a mechanism that allows consenting 281 parties to establish a relationship with guaranteed delivery within 282 a specified time, or notification that the delivery was not 283 achieved. 285 Further goals are: 287 o Provide "while-you-wait" delivery of facsimile messages by e-mail 288 (where available infrastructure and connectivity permits). 290 o Deterministic behaviour. A sender who requests timely delivery 291 should be able to determine with reasonable certainty whether or 292 not that request was successful. 294 Content Negotiation for Internet Fax 13 September 295 297 o If the message cannot be delivered as requested, it should not be 298 delivered at all. This means that a sender can take control over 299 alternative strategies for message delivery (e.g. if timely 300 delivery by e-mail does not succeed, to resend the message as a 301 traditional facsimile; in such circumstances it is preferable 302 that multiple copies of the message are not delivered. 304 o Operates within the existing ESMTP extension framework [3],using 305 existing facilities where available. 307 3. Mechanisms for timely delivery 309 Timely delivery is achieved through a number of ESMTP extensions 310 used in concert: 312 o Delivery Status Notification ("DSN"), per RFC 1891 [4]. 314 o Deliver-by ("DELIVERBY"), per RFC 2852 [5] 316 o A new "Compliance-required" extension, that serves to modify the 317 SMTP contract and also to establish that the receiving user agent 318 can process the message in timely fashion as required. 320 The confirmation loop for succesful delivery looks something like 321 this. The path through MTAs taken by the confirmation response is 322 not defined, and may be different than the forward path of the 323 original message. 325 +-----------+ +--------+ +--------+ +---------+ 326 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 327 | MTA | | MTA | | MTA | --| MTA | 328 +-----------+ +--------+ +--------+ | +---------+ 329 | | | 330 +-------------+ | +---------+ 331 | Originating |--<-- ... .... ... --<-- |Receiving| 332 | MUA | | MUA | 333 +-------------+ +---------+ 335 3.1 Transmitting a message for timely delivery 337 A transmitted message for which timely delivery is required MUST 338 include the following: 340 o an 'ENVID' parameter on the MAIL command, per DSN [4] 342 o a 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT 343 command, per DSN [4] 345 o an 'ORCPT' parameter on the MAIL command, per DSN [4] 346 Content Negotiation for Internet Fax 13 September 347 349 o a 'BY' parameter on the corresponding RCPT command, per [5], with 350 a 'by-mode' value of 'R'. 352 o a 'COMPLIANCE=TIMELY' parameter on the corresponding RCPT, as 353 described below. 355 The message MUST NOT be transmitted to any MTA that does not 356 indicate support for all of these extensions in its response to the 357 EHLO command. In this case, a negative delivery status report MUST 358 be generated indicating the non-compliant MTA, the extensions that 359 it does not support, and the name of the reporting MTA (per DSN, 360 using the non-compliance reporting extensions noted below). 362 3.2 Relaying a message 364 An MTA that relays a message for timely delivery MUST support all 365 of the ESMTP extensions noted above, otherwise it should not 366 receive the message in the first place. When a relaying MTA 367 accepts a message (by its 2xx status response to receipt of the 368 message data), it becomes responsible for its onward delivery, 369 including satisfying all of the options associated with the 370 message. 372 In order to relay a message, an MTA must note when the message was 373 received, note the time when the attempt to transmit the message to 374 the next MTA is initiated, and reduce accordingly the time interval 375 used for the 'deliver-by' parameter (see note below on handling 376 fine-grained timing requirements). 378 If the deliver-by interval is reduced to less than zero, (or less 379 than some system-configurable value indicating that delivery within 380 the indicated interval is unlikely to be achieved) then the message 381 MUST NOT be relayed. Instead, a negative delivery status report 382 MUST be generated indicating that the time for delivery of the 383 message has expired, and the reporting MTA (per DSN, using the 384 deliver-by extensions and/or non-compliance reporting extensions 385 noted below). 387 [[[Remove duplication between above and DELIVERBY spec]]] 389 If the first attempt to relay a message fails, the relaying MTA MAY 390 assume that delivery within the desired time will not be achieved, 391 and immediately indicate a delivery failure, indicating the name of 392 the next-hop MTA. Alternatively, the relaying MTA may wait and 393 retry the transmission, provided that the retry attempt will be 394 performed within the remaining deliver-by period; if the 395 transmission cannot be completed after one or more such retries 396 then a negative DSN should be generated as noted above. 398 Content Negotiation for Internet Fax 13 September 399 401 In all cases, any DSN generated should indicate the number of 402 retries attempted (where 0 means no retries). 404 The choice to retry or not retry is installation dependent. 405 Effectively, when a relay does not retry, any reposibility for 406 overcoming the delivery failure is passed back to the original 407 sender. This strategy may be appropriate for cases where very 408 rapid delivery is required or expected. 410 NOTE: The presence of a 'COMPLIANCE=TIMELY' option may 411 cause a relay to abandon a message that it would 412 otherwise retry (even given a 'by-mode' value of 'R'). 413 The intent of this option is to establish that 414 responsiveness to the sender is more important than 415 getting the message through. One effect of this may be 416 to severely constrain the number and frequency of retry 417 attempts. 419 3.3 Accepting a message by the final MTA 421 The MTA that accepts final delivery of a message has responsibility 422 for passing the message to a Mail User Agent. The exact mechanism 423 by which this is achieved is a local matter, and not defined here 424 or by the Internet e-mail specifications. The final MTA is also 425 responsible for generating any successful DSN message. 427 Before generating a DSN message, the final MTA must ensure that all 428 of the conditions for delivery of the message have been achieved. 430 Specifically, it should ensure that final delivery to the MTA will 431 be completed within the DELIVER-BY interval indicated. Exactly 432 what constitutes final delivery to the MTA may depend somewhat on 433 the nature of the MTA: in the simplest case, depositing the 434 message in a local mailbox probably constitutes final delivery; a 435 more complex case would be that of a fax offramp: in this case it 436 may be reasonable for final delivery to be completion of a 437 successful outdial and transmission of the fax. 439 In the presence of a 'COMPLIANCE=TIMELY' option, final delivery 440 should not be completed unless the delivery MTA can establish that 441 the receiving MUA will deal with the message promptly. Here 442 "promptly" means a reasonable waiting time for a human; e.g. that 443 the message (or at least the start of the message) will be 444 available to its intended final recipient in a time comparable with 445 that taken to establish a telephone call. 447 [[[DISCUSS: In environments where the timing of final delivery of 448 the message is outside the control of the final MTA (e.g. the time 449 required for an outdial, or waiting for a client to collect the 450 message), an interim DSN report may be generated indicating that 451 Content Negotiation for Internet Fax 13 September 452 454 the message has been received pending final delivery. This report 455 should be clear whether final delivery is dependent on the 456 receiving user (e.g. mail collection) or some other unknown 457 infrastructure delay (e.g. fax out-dial or external e-mail 458 environment).]]] 460 [[[I think the above is verging on trying to be too clever, getting 461 too far into MDN teritory]]] 463 3.4 Timely confirmation 465 Fully deterministic behaviour requires that the round-trip time to 466 deliver a message and receive a response is completed within a 467 known time interval. 469 As noted above, it cannot be guaranteed that confirmation of 470 delivery or non-delivery will be transferred in timely fashion. It 471 seems reasonable to assume that return path transit times will 472 normally be comparable with forward path times. 474 Further, it is likely that perfect determinism can never be 475 achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are 476 probably less harmful than lost messages, but even these should be 477 minimized. 479 The following behaviour is proposed for achieving nearly 480 deterministic behaviour: 482 o Always fail forward delivery if non-TIMELY MTA is encountered. 484 o Use the DELIVER-BY option to request timely delivery for DSN 485 return, using same total time (x2?) as forward path, but 486 specifying a 'by-mode' value of 'N' rather than 'R'. 488 o Use a high priority option for the DSN return (for MTAs that may 489 take note of such things). 491 o Do NOT fail notification delivery if non-TIMELY or non-DELIVER-BY 492 MTA is encountered on the return path. 494 o The return DSN does not itself request delivery-notification (as 495 required by DSN). 497 o Sender may assume that message is lost after some multiple of 498 original DELIVER-BY interval has passed without notificaton (x4 499 is suggested). 501 o Sender is required to provide envelope ID with message. If it 502 re-tries, it should use same envelope ID and should do so within 503 Content Negotiation for Internet Fax 13 September 504 506 some multiple of DELIVER-BY interval (x6 suggested) since the 507 last retry. 509 o The receiver of a TIMELY message is strongly encouraged to keep 510 note of received envelope ID for some multiple of the DELIVER-BY 511 interval (x8 suggested) for the purpose of weeding out 512 duplicates. 514 4. Compliance-required ESMTP extension 516 [[[TBD]]] 518 Essentially, the semantics will be to REQUIRE conformance to any 519 SMTP extensions used for delivery to be successfully completed. 521 Unlike declared ESMTP extensions, this option requires the 522 extensions to be applied for a specific message. 524 [[[A simpler approach might be to simply define an extension and 525 parameter called TIMELY whose semantics are similar to those 526 attributed to COMPLIANCE=TIMELY.]]] 528 5. DSN reporting extensions 530 [[[Details TBD]]] 532 - Extension not supported 534 - Delivery time exceeded 536 - Delivered for further transmission: final confirmation pending 537 [[[???]]] 539 - Delivered for collection by user: final confimation pending 540 [[[???]]] 542 6. Notes 544 [[[These are placeholders for further discussion]]] 546 - Use of alternative port (e.g. like message submission). 548 - Scalability analysis. Required state information -- all at the 549 edges? 550 Content Negotiation for Internet Fax 13 September 551 553 - Handling fine-grained timing requirements (deliver-by 554 modification and implementation techniques). Must assume deliver- 555 by interval is large relative to normal network transit times. 557 - Partial non-delivery: failure to some recipients. Must be 558 handled, since all-or-nothing cannot be imposed within the SMTP 559 transfer environment. 561 7. Examples 563 [[[TBD]]] 565 8. IANA Considerations 567 [[[TBD: ESMTP and DSN extension registrations]]] 569 9. Internationalization considerations 571 [[[TBD?]]] 573 10. Security considerations 575 [[[TBD]]] 577 11. Acknowledgements 579 The authors thank Hiroshi Tamura-san for undertaking the task of 580 reviewing a very rough, early draft and making several pertinent 581 observations. 583 12. References 585 [1] RFC 2542, "Terminology and Goals for Internet Fax" 586 L. Masinter, Xerox Corporation 587 March 1999. 589 [2] RFC 821, "Simple Mail Transfer Protocol" 590 Jonathan B. Postel, ISI/USC 591 August 1982. 593 Content Negotiation for Internet Fax 13 September 594 596 [3] RFC 1651, "SMTP Service Extensions" 597 J. Klensin, MCI 598 N. Freed, Innosoft 599 M. Rose, Dover Beach Consulting, Inc. 600 E. Stefferud, Network Management Associates, Inc. 601 D. Crocker, Silicon Graphics, Inc. 602 July 1994. 604 [4] RFC 1891, "SMTP Service Extension for Delivery Status 605 Notifications" 606 K. Moore, University of Tennessee 607 January 1996. 609 [5] RFC 2852, "Deliver By SMTP Service Extension" 610 D. Newman, Sun Microsystems 611 June 2000 613 [6] 615 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 616 D. Crocker (editor), Internet Mail Consortium 617 P. Overell, Demon Internet Ltd. 618 November 1997. 620 [8] T.30 622 [9] RFC 1047 624 13. Authors' addresses 626 Graham Klyne (editor) 627 Content Technologies Ltd. 628 1220 Parkview, 629 Arlington Business Park 630 Theale 631 Reading, RG7 4SA 632 United Kingdom. 633 Telephone: +44 118 930 1300 634 Facsimile: +44 118 930 1301 635 E-mail: GK@ACM.ORG 637 [[[et. al. TBD]]] 638 Content Negotiation for Internet Fax 13 September 639 641 Appendix A: Amendment history 643 00a 22-Oct-1999 Memo initially created. 645 01a 13-Sep-1999 Incorporate review comments. Update references. 646 Changed title. Incorporate material from IETF 647 meeting presentations. 649 TODO: 651 Full copyright statement 653 Copyright (C) The Internet Society 2000. All Rights Reserved. 655 This document and translations of it may be copied and furnished to 656 others, and derivative works that comment on or otherwise explain 657 it or assist in its implementation may be prepared, copied, 658 published and distributed, in whole or in part, without restriction 659 of any kind, provided that the above copyright notice and this 660 paragraph are included on all such copies and derivative works. 661 However, this document itself may not be modified in any way, such 662 as by removing the copyright notice or references to the Internet 663 Society or other Internet organizations, except as needed for the 664 purpose of developing Internet standards in which case the 665 procedures for copyrights defined in the Internet Standards process 666 must be followed, or as required to translate it into languages 667 other than English. 669 The limited permissions granted above are perpetual and will not be 670 revoked by the Internet Society or its successors or assigns. 672 This document and the information contained herein is provided on 673 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 674 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 675 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.