idnits 2.17.1 draft-etal-apex-party-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 document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 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 (May 16, 2001) is 8373 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) == Outdated reference: A later version (-06) exists of draft-ietf-apex-core-01 ** Downref: Normative reference to an Historic draft: draft-ietf-apex-core (ref. '1') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Dixon 3 Internet-Draft H. Franklin 4 Expires: November 14, 2001 J. Kint 5 Invisible Worlds, Inc. 6 G. Klyne 7 Baltimore Technologies 8 D. New 9 S. Pead 10 M. Rose 11 Invisible Worlds, Inc. 12 May 16, 2001 14 The APEX Option Party Pack, Part Deux! 15 draft-etal-apex-party-01 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 14, 2001. 40 Copyright Notice 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 Abstract 46 APEX, at its core, provides a best-effort application-layer datagram 47 service. Options are used to alter the semantics of the core 48 service. This memo defines various options to change the default 49 behavior of APEX's "relaying mesh". 51 Table of Contents 53 1. The attachOverride Option . . . . . . . . . . . . . . . . . 3 54 2. The dataTiming Option . . . . . . . . . . . . . . . . . . . 5 55 2.1 Upper-Bounds on Delivery . . . . . . . . . . . . . . . . . . 6 56 2.1.1 Final Hop Report . . . . . . . . . . . . . . . . . . . . . . 7 57 2.1.2 Timing Error Report . . . . . . . . . . . . . . . . . . . . 9 58 2.2 Reporting on Delayed Delivery . . . . . . . . . . . . . . . 11 59 2.2.1 Transient Timing Report . . . . . . . . . . . . . . . . . . 12 60 3. The hold4Endpoint Option . . . . . . . . . . . . . . . . . . 14 61 4. Initial Registrations . . . . . . . . . . . . . . . . . . . 16 62 4.1 Registration: The attachOverride Option . . . . . . . . . . 16 63 4.2 Registration: The dataTiming Option . . . . . . . . . . . . 16 64 4.3 Registration: The hold4Endpoint Option . . . . . . . . . . . 16 65 5. The APEX Party Pack DTD . . . . . . . . . . . . . . . . . . 17 66 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 67 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 69 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 70 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 71 C. Changes from draft-etal-apex-party-00 . . . . . . . . . . . 23 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 24 74 1. The attachOverride Option 76 Section 4.1 contains the APEX option registration for the 77 "attachOverride" option. 79 The default behavior of the APEX relaying mesh, in the absence of 80 processing options, is to allow at most one application to attach as 81 a particular endpoint, on a "first come, first served" basis. The 82 "attachOverride" option provides gives preference to the current 83 application trying to attach. 85 If this option is present in the "attach" operation (c.f., Section 86 4.4.1 of [1]) and if any application is already attached as the 87 specified endpoint, that endpoint has its attachment terminated 88 (c.f., Section 4.4.3 of [1]) concurrently with processing of that 89 "attach" operation. 91 Note that any data being expected by the previously-attached 92 application may instead be delivered to the last application to 93 successfully attach. Accordingly, applications should take care to 94 properly deal with incoming data having unrecognized transaction- 95 identifiers (c.f., Section 6.1.1 of [1]). 97 This option provides for a new attachment to automatically terminate 98 any existing attachment for the same endpoint. For example, This 99 might be helpful when a new attachment is required from a different 100 device while a previously-used device is still attached e.g., 102 +-------+ +-------+ 103 | | -- attach -----> | | 104 | appl. | | relay | 105 | #1 | <--------- ok -- | | 106 +-------+ +-------+ 108 C: 109 S: 111 ... some time later appl #2 starts on a different computer ... 113 +-------+ +-------+ 114 | | <----- attach -- | | 115 +-------+ | | | appl. | 116 | | <-- terminate -- | relay | -- ok ---------> | #2 | 117 | appl. | | | +-------+ 118 | #1 | -- ok ---------> | | 119 +-------+ +-------+ 121 C: 122 124 S: 126 C: 127 S: 129 2. The dataTiming Option 131 Section 4.2 contains the APEX option registration for the 132 "dataTiming" option. This option contains a "dataTiming" element 133 (c.f., Section 5). 135 The default behavior of the APEX relaying mesh is "immediate, best 136 effort" and expects that all relays and endpoints are able to process 137 and transfer data without delay -- in the absence of processing 138 options, if a relay is unavailable then data is silently dropped. 139 The "dataTiming" option provides for controlled queuing delays in 140 processing, whilst providing reasonable deterministic behavior for 141 the originator. 143 There are two types of delay addressed by the "dataTiming" option: 145 o delays in transit through the relaying mesh, possibly due to 146 intermittent or slow connections, or congested relays; and, 148 o delays because the intended endpoint is not available to receive 149 the data, when used in conjunction with the hold4Endpoint option 150 (Section 3). 152 Accordingly, the "dataTiming" option allows for: 154 o data to be discarded if not delivered within a finite amount of 155 time as specified using the "noLaterThan" attribute (Section 2.1); 156 and, 158 o a "statusResponse" message (c.f., Section 5.1 of [1]) to be 159 generated if data is not delivered within a finite amount of time 160 as specified using the "reportAfter" attribute (Section 2.2). 162 This option does not provide any functionality with respect to the 163 priority of the data. Nor does this option have any effect on other 164 parts of the relaying process. 166 Further, note that because this option is processed on a per-hop 167 basis, the originator must set the "targetHop" attribute to the value 168 "all" and the "mustUnderstand" attribute to the value "true". 170 2.1 Upper-Bounds on Delivery 172 The "noLaterThan" attribute of the "dataTiming" option provides for 173 control over delays that may occur in transit through the relaying 174 mesh or to the recipient endpoint. 176 If this option is present in the "data" operation (c.f., Section 177 4.4.4 of [1]) and the value of the "noLaterThan" attribute is non- 178 zero, then: 180 o For Step 5.2 of Section 4.4.4.1 of [1]: 182 Immediately prior to sending the data to the next relay, the value 183 of the "noLaterThan" attribute is adjusted to reflect the 184 processing time of the data at the local relay (e.g., the time 185 required to determine the next relay, to successfully issue a 186 "bind" operation, and then be ready to immediately issue a "data" 187 operation). 189 If the value of the "noLaterThan" attribute becomes less than or 190 equal to zero, an error in processing has occurred, the data 191 element is not sent to the next relay, and if the "reportErrors" 192 attribute is true, the APEX report service is invokved to send a 193 timing error report. 195 o For Step 5.3 of Section 4.4.4.1 of [1]: 197 If the relay does not receive an "ok" element from the recipient 198 endpoint within the number of milli-seconds indicated by the value 199 of the "noLaterThan" attribute, an error in processing has 200 occurred, and if the "reportErrors" attribute is true, the APEX 201 report service is invoked to send a timing error report. 203 Otherwise, if the data is successfully transmitted to the 204 recipient, and the "returnTrip" attribute is non-zero, the APEX 205 report service is invoked to send a final hop report. 207 2.1.1 Final Hop Report 209 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to 210 send a final hop report, it issues a data operation with: 212 o its originator identifying the report service associated with the 213 issuing relay 215 o its recipient identifying the endpoint address of the originator 216 associated with the "dataTiming" option 218 o a new "dataTiming" option having: 220 * its "noLaterThan" attribute equal to the "returnTrip" attribute 221 of the original "dataTiming" option 223 * and no other attributes present 225 o its content consisting of a "statusResponse" element having: 227 * its "transID" attribute equal to the "transID" attribute of the 228 "dataTiming" option 230 * and identifying the original recipient with a permanent success 231 indicator 233 For example: 235 +-------+ +-------+ 236 | | -- data -------> | | 237 | relay | | appl. | 238 | | <--------- ok -- | #2 | 239 +-------+ +-------+ 241 C: 242 243 244 248 249 S: 251 +-------+ +-------+ 252 | | <------- data -- | | 253 | appl. | | relay | 254 | #1 | -- ok ---------> | | 255 +-------+ +-------+ 257 C: 258 259 260 264 265 266 267 268 269 270 271 272 S: 274 2.1.2 Timing Error Report 276 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to 277 send a timing error report, it issues a data operation with: 279 o its originator identifying the report service associated with the 280 issuing relay 282 o its recipient identifying the endpoint address of the originator 283 associated with the "dataTiming" option 285 o its content consisting of a "statusResponse" element having: 287 * its "transID" attribute equal to the "transID" attribute of the 288 "dataTiming" option 290 * and identifying the original recipient with a permanent failure 291 indicator 293 For example: 295 +-------+ +-------+ 296 | | -- data -------> | | 297 | appl. | | relay | 298 | | <--------- ok -- | | 299 +-------+ +-------+ 301 C: 302 303 304 308 309 S: 311 ... some time later ... 313 +-------+ +-------+ 314 | | <------- data -- | | 315 | appl. | | relay | 316 | | -- ok ---------> | | 317 +-------+ +-------+ 319 C: 320 321 322 323 324 325 326 327 328 329 330 S: 332 2.2 Reporting on Delayed Delivery 334 The "reportAfter" attribute of the "dataTiming" option provides for 335 the originator to be notified if delivery is delayed beyond a 336 specified time. Delivery of the data is not affected. Note that if 337 the value of the "noLaterThan" attribute is non-zero, then it 338 provides the operational upper-bounds for the "reportAfter" 339 attribute. 341 If this option is present in the "data" operation (c.f., Section 342 4.4.4 of [1]) and the value of the "reportAfter" attribute is non- 343 zero, then: 345 o For Step 5.2 of Section 4.4.4.1 of [1]: 347 Immediately prior to sending the data to the next relay, the value 348 of the "reportAfter" attribute is adjusted to reflect the 349 processing time of the data at the local relay (e.g., the time 350 required to determine the next relay, to successfully issue a 351 "bind" operation, and then be ready to immediately issue a "data" 352 operation). 354 If the value of the "reportAfter" attribute becomes less than or 355 equal to zero, then its value is set to zero and the APEX report 356 service is invoked to send a transient timing report; regardless, 357 the data element is sent to the next relay. 359 o For Step 5.3 of Section 4.4.4.1 of [1]: 361 If the relay does not receive an "ok" element from the recipient 362 endpoint within the number of milli-seconds indicated by the value 363 of the "reportAfter" attribute, then its value is set to zero and 364 the APEX report service is invoked to send a transient timing 365 report. 367 2.2.1 Transient Timing Report 369 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to 370 send a timing error report, it issues a data operation with: 372 o its originator identifying the report service associated with the 373 issuing relay 375 o its recipient identifying the endpoint address of the originator 376 associated with the "dataTiming" option 378 o its content consisting of a "statusResponse" element having: 380 * its "transID" attribute equal to the "transID" attribute of the 381 "dataTiming" option 383 * and identifying the original recipient with a transient success 384 indicator 386 For example: 388 +-------+ +-------+ 389 | | -- data -------> | | 390 | appl. | | relay | 391 | #1 | <--------- ok -- | | 392 +-------+ +-------+ 394 C: 395 396 397 401 402 S: 404 ... some time later ... 406 +-------+ +-------+ 407 | | <------- data -- | | 408 | relay | | relay | 409 | #n-1 | -- ok ---------> | #n | 410 +-------+ +-------+ 412 C: 413 414 415 416 417 418 419 420 421 422 423 S: 425 3. The hold4Endpoint Option 427 Section 4.3 contains the APEX option registration for the 428 "hold4Endpoint" option. 430 The default behavior of the APEX relaying mesh, in the absence of 431 processing options, is to silently drop data for a recipient if its 432 endpoint isn't attached. The "hold4Endpoint" option provides for 433 data to be queued if the recipient endpoint is not attached. 435 If this option is present in the "data" operation (c.f., Section 436 4.4.4 of [1]), and the value of the "hold4Endpoint" attribute is true 437 then: 439 o For Step 5.3 of Section 4.4.4.1 of [1]: 441 If the recipient's endpoint is not currently attached, the relay 442 will queue the data waiting for an application to attach as that 443 endpoint. 445 Note that in the absence of an upper-bounds on delivery, such as 446 limits provided by the dataTiming option (Section 2), the data will 447 be queued indefinitely for the endpoint. 449 For example: 451 +-------+ +-------+ 452 | | -- data -------> | | 453 | appl. | | relay | 454 | #1 | <--------- ok -- | | 455 +-------+ +-------+ 457 C: 458 459 460 465 466 S: 468 ... some time later the recipient's endpoint attaches ... 470 +-------+ +-------+ 471 | | <----- attach -- | | 472 | | | | 473 | | -- ok ---------> | | 474 | relay | | appl. | 475 | | -- data -------> | #2 | 476 | | | | 477 | | <--------- ok -- | | 478 +-------+ +-------+ 480 C: 481 483 S: 485 C: 486 487 488 493 494 S: 496 4. Initial Registrations 498 The APEX option registration template is defined in Section 7.1 of 499 [1]. 501 4.1 Registration: The attachOverride Option 503 Option Identification: attachOverride 505 Present in: APEX's "attach" element 507 Contains: nothing 509 Processing Rules: c.f., Section 1 511 Contact Information: c.f., the "Authors' Addresses" section of this 512 memo 514 4.2 Registration: The dataTiming Option 516 Option Identification: dataTiming 518 Present in: APEX's "data" element 520 Contains: dataTiming (c.f., Section 5) 522 Processing Rules: c.f., Section 2 524 Contact Information: c.f., the "Authors' Addresses" section of this 525 memo 527 4.3 Registration: The hold4Endpoint Option 529 Option Identification: hold4Endpoint 531 Present in: APEX's "data" element 533 Contains: nothing 535 Processing Rules: c.f., Section 3 537 Contact Information: c.f., the "Authors' Addresses" section of this 538 memo 540 5. The APEX Party Pack DTD 542 552 554 %APEXCORE; 556 565 567 568 575 6. Security Considerations 577 Consult [1]'s Section 11 for a discussion of security issues. 579 In addition: 581 o The dataTiming option (Section 2) may be used to expose private 582 network topology. Accordingly, an administrator may wish to 583 choose to disable this option except at the ingress/egress points 584 for its administrative domain. 586 o The hold4Endpoint option (Section 3) may be used to facilitate 587 denial-of-service attacks. Accordingly, an administrator may wish 588 to impose administrative limits on this attribute (e.g., always 589 require that the "dataTiming" option also be present with a short- 590 lived "noLaterThan" attribute). 592 References 594 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange 595 Core", draft-ietf-apex-core-01 (work in progress), May 2001. 597 [2] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 598 2000. 600 Authors' Addresses 602 Eric Dixon 603 Invisible Worlds, Inc. 604 131 Stony Circle 605 Suite 500 606 Santa Rosa, CA 95401 607 US 609 Phone: +1 707 578 2350 610 EMail: edixon@invisible.net 611 URI: http://invisible.net/ 613 Huston Franklin 614 Invisible Worlds, Inc. 615 131 Stony Circle 616 Suite 500 617 Santa Rosa, CA 95401 618 US 620 Phone: +1 707 578 2350 621 EMail: huston@invisible.net 622 URI: http://invisible.net/ 624 Jay Kint 625 Invisible Worlds, Inc. 626 131 Stony Circle 627 Suite 500 628 Santa Rosa, CA 95401 629 US 631 Phone: +1 707 578 2350 632 EMail: jkint@invisible.net 633 URI: http://invisible.net/ 634 Graham Klyne 635 Baltimore Technologies 636 1310 Waterside 637 Arlington Business Park 638 Theale, Reading RG7 4SA 639 UK 641 Phone: +44 118 903 8000 642 EMail: gk@acm.org 644 Darren New 645 Invisible Worlds, Inc. 646 131 Stony Circle 647 Suite 500 648 Santa Rosa, CA 95401 649 US 651 Phone: +1 707 578 2350 652 EMail: dnew@invisible.net 653 URI: http://invisible.net/ 655 Scott Pead 656 Invisible Worlds, Inc. 657 131 Stony Circle 658 Suite 500 659 Santa Rosa, CA 95401 660 US 662 Phone: +1 707 578 2350 663 EMail: spead@invisible.net 664 URI: http://invisible.net/ 666 Marshall T. Rose 667 Invisible Worlds, Inc. 668 131 Stony Circle 669 Suite 500 670 Santa Rosa, CA 95401 671 US 673 Phone: +1 707 578 2350 674 EMail: mrose@invisible.net 675 URI: http://invisible.net/ 677 Appendix A. Acknowledgements 679 The authors gratefully acknowledge the contributions of Chris Newman; 680 further, the dataTiming option is similar in function to "Deliver By" 681 SMTP service extension defined by Dan Newman in [2]. 683 Appendix B. IANA Considerations 685 The IANA makes the registrations specified in Section 4. 687 Appendix C. Changes from draft-etal-apex-party-00 689 o Rename the "roundTrip" attribute to "returnTrip". 691 o Update the examples to reflect milli-seconds instead of seconds. 693 o Remove "targetHop='all'" from "hold4Endpoint" examples. 695 o Various typos. 697 Full Copyright Statement 699 Copyright (C) The Internet Society (2001). All Rights Reserved. 701 This document and translations of it may be copied and furnished to 702 others, and derivative works that comment on or otherwise explain it 703 or assist in its implementation may be prepared, copied, published 704 and distributed, in whole or in part, without restriction of any 705 kind, provided that the above copyright notice and this paragraph are 706 included on all such copies and derivative works. However, this 707 document itself may not be modified in any way, such as by removing 708 the copyright notice or references to the Internet Society or other 709 Internet organizations, except as needed for the purpose of 710 developing Internet standards in which case the procedures for 711 copyrights defined in the Internet Standards process must be 712 followed, or as required to translate it into languages other than 713 English. 715 The limited permissions granted above are perpetual and will not be 716 revoked by the Internet Society or its successors or assigns. 718 This document and the information contained herein is provided on an 719 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 720 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 721 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 722 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 723 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Acknowledgement 727 Funding for the RFC Editor function is currently provided by the 728 Internet Society.