Network Working Group E. Dixon Internet-Draft H. Franklin Expires: November 12, 2001 J. Kint Invisible Worlds, Inc. G. Klyne Baltimore Technologies D. New S. Pead M. Rose Invisible Worlds, Inc. May 14, 2001 The APEX Option Party Pack, Part Deux! draft-etal-apex-party-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 12, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract APEX, at its core, provides a best-effort application-layer datagram service. Options are used to alter the semantics of the core service. This memo defines various options to change the default behavior of APEX's "relaying mesh". Dixon, et. al. Expires November 12, 2001 [Page 1] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 Table of Contents 1. The attachOverride Option . . . . . . . . . . . . . . . . . 3 2. The dataTiming Option . . . . . . . . . . . . . . . . . . . 5 2.1 Upper-Bounds on Delivery . . . . . . . . . . . . . . . . . . 6 2.1.1 Final Hop Report . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Timing Error Report . . . . . . . . . . . . . . . . . . . . 9 2.2 Reporting on Delayed Delivery . . . . . . . . . . . . . . . 11 2.2.1 Transient Timing Report . . . . . . . . . . . . . . . . . . 12 3. The hold4Endpoint Option . . . . . . . . . . . . . . . . . . 14 4. Initial Registrations . . . . . . . . . . . . . . . . . . . 16 4.1 Registration: The attachOverride Option . . . . . . . . . . 16 4.2 Registration: The dataTiming Option . . . . . . . . . . . . 16 4.3 Registration: The hold4Endpoint Option . . . . . . . . . . . 16 5. The APEX Party Pack DTD . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 Dixon, et. al. Expires November 12, 2001 [Page 2] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 1. The attachOverride Option Section 4.1 contains the APEX option registration for the "attachOverride" option. The default behavior of the APEX relaying mesh, in the absence of processing options, is to allow at most one application to attach as a particular endpoint, on a "first come, first served" basis. The "attachOverride" option provides gives preference to the current application trying to attach. If this option is present in the "attach" operation (c.f., Section 4.4.1 of [1]) and if any application is already attached as the specified endpoint, that endpoint has its attachment terminated (c.f., Section 4.4.3 of [1]) concurrently with processing of that "attach" operation. Note that any data being expected by the previously-attached application may instead be delivered to the last application to successfully attach. Accordingly, applications should take care to properly deal with incoming data having unrecognized transaction- identifiers (c.f., Section 6.1.1 of [1]). This option provides for a new attachment to automatically terminate any existing attachment for the same endpoint. For example, This might be helpful when a new attachment is required from a different device while a previously-used device is still attached e.g., +-------+ +-------+ | | -- attach -----> | | | appl. | | relay | | #1 | <--------- ok -- | | +-------+ +-------+ C: S: ... some time later appl #2 starts on a different computer ... Dixon, et. al. Expires November 12, 2001 [Page 3] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 +-------+ +-------+ | | <----- attach -- | | +-------+ | | | appl. | | | <-- terminate -- | relay | -- ok ---------> | #2 | | appl. | | | +-------+ | #1 | -- ok ---------> | | +-------+ +-------+ C: S: C: S: Dixon, et. al. Expires November 12, 2001 [Page 4] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2. The dataTiming Option Section 4.2 contains the APEX option registration for the "dataTiming" option. This option contains a "dataTiming" element (c.f., Section 5). The default behavior of the APEX relaying mesh is "immediate, best effort" and expects that all relays and endpoints are able to process and transfer data without delay -- in the absence of processing options, if a relay is unavailable then data is silently dropped. The "dataTiming" option provides for controlled queuing delays in processing, whilst providing reasonable deterministic behavior for the originator. There are two types of delay addressed by the "dataTiming" option: o delays in transit through the relaying mesh, possibly due to intermittent or slow connections, or congested relays; and, o delays because the intended endpoint is not available to receive the data, when used in conjunction with the hold4Endpoint option (Section 3). Accordingly, the "dataTiming" option allows for: o data to be discarded if not delivered within a finite amount of time as specified using the "noLaterThan" attribute (Section 2.1); and, o a "statusResponse" message (c.f., Section 5.1 of [1]) to be generated if data is not delivered within a finite amount of time as specified using the "reportAfter" attribute (Section 2.2). This option does not provide any functionality with respect to the priority of the data. Nor does this option have any effect on other parts of the relaying process. Further, note that because this option is processed on a per-hop basis, the originator must set the "targetHop" attribute to the value "all" and the "mustUnderstand" attribute to the value "true". Dixon, et. al. Expires November 12, 2001 [Page 5] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2.1 Upper-Bounds on Delivery The "noLaterThan" attribute of the "dataTiming" option provides for control over delays that may occur in transit through the relaying mesh or to the recipient endpoint. If this option is present in the "data" operation (c.f., Section 4.4.4 of [1]) and the value of the "noLaterThan" attribute is non- zero, then: o For Step 5.2 of Section 4.4.4.1 of [1]: Immediately prior to sending the data to the next relay, the value of the "noLaterThan" attribute is adjusted to reflect the processing time of the data at the local relay (e.g., the time required to determine the next relay, to successfully issue a "bind" operation, and then be ready to immediately issue a "data" operation). If the value of the "noLaterThan" attribute becomes less than or equal to zero, an error in processing has occurred, the data element is not sent to the next relay, and if the "reportErrors" attribute is true, the APEX report service is invokved to send a timing error report. o For Step 5.3 of Section 4.4.4.1 of [1]: If the relay does not receive an "ok" element from the recipient endpoint within the number of milli-seconds indicated by the value of the "noLaterThan" attribute, an error in processing has occurred, and if the "reportErrors" attribute is true, the APEX report service is invokved to send a timing error report. Otherwise, if the data is successfully transmitted to the recipient, and the "roundTrip" attribute is true, the APEX report service is invoked to send a final hop report. Dixon, et. al. Expires November 12, 2001 [Page 6] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2.1.1 Final Hop Report If the APEX report service (c.f., Section 6.2 of [1]) is invoked to send a final hop report, it issues a data operation with: o its originator identifying the report service associated with the issuing relay o its recipient identifying the endpoint address of the originator associated with the "dataTiming" option o a new "dataTiming" option having: * its "noLaterThan" attribute equal to the "roundTrip" attribute of the original "dataTiming" option * and no other attributes present o its content consisting of a "statusResponse" element having: * its "transID" attribute equal to the "transID" attribute of the "dataTiming" option * and identifying the original recipient with a permanent success indicator Dixon, et. al. Expires November 12, 2001 [Page 7] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 For example: +-------+ +-------+ | | -- data -------> | | | relay | | appl. | | | <--------- ok -- | #2 | +-------+ +-------+ C: S: +-------+ +-------+ | | <------- data -- | | | appl. | | relay | | #1 | -- ok ---------> | | +-------+ +-------+ C: S: Dixon, et. al. Expires November 12, 2001 [Page 8] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2.1.2 Timing Error Report If the APEX report service (c.f., Section 6.2 of [1]) is invoked to send a timing error report, it issues a data operation with: o its originator identifying the report service associated with the issuing relay o its recipient identifying the endpoint address of the originator associated with the "dataTiming" option o its content consisting of a "statusResponse" element having: * its "transID" attribute equal to the "transID" attribute of the "dataTiming" option * and identifying the original recipient with a permanent failure indicator For example: +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+ C: S: ... some time later ... Dixon, et. al. Expires November 12, 2001 [Page 9] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 +-------+ +-------+ | | <------- data -- | | | appl. | | relay | | | -- ok ---------> | | +-------+ +-------+ C: S: Dixon, et. al. Expires November 12, 2001 [Page 10] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2.2 Reporting on Delayed Delivery The "reportAfter" attribute of the "dataTiming" option provides for the originator to be notified if delivery is delayed beyond a specified time. Delivery of the data is not affected. Note that if the value of the "noLaterThan" attribute is non-zero, then it provides the operational upper-bounds for the "reportAfter" attribute. If this option is present in the "data" operation (c.f., Section 4.4.4 of [1]) and the value of the "reportAfter" attribute is non- zero, then: o For Step 5.2 of Section 4.4.4.1 of [1]: Immediately prior to sending the data to the next relay, the value of the "reportAfter" attribute is adjusted to reflect the processing time of the data at the local relay (e.g., the time required to determine the next relay, to successfully issue a "bind" operation, and then be ready to immediately issue a "data" operation). If the value of the "reportAfter" attribute becomes less than or equal to zero, then its value is set to zero and the APEX report service is invoked to send a transient timing report; regardless, the data element is sent to the next relay. o For Step 5.3 of Section 4.4.4.1 of [1]: If the relay does not receive an "ok" element from the recipient endpoint within the number of milli-seconds indicated by the value of the "reportAfter" attribute, then its value is set to zero and the APEX report service is invoked to send a transient timing report. Dixon, et. al. Expires November 12, 2001 [Page 11] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 2.2.1 Transient Timing Report If the APEX report service (c.f., Section 6.2 of [1]) is invoked to send a timing error report, it issues a data operation with: o its originator identifying the report service associated with the issuing relay o its recipient identifying the endpoint address of the originator associated with the "dataTiming" option o its content consisting of a "statusResponse" element having: * its "transID" attribute equal to the "transID" attribute of the "dataTiming" option * and identifying the original recipient with a transient success indicator For example: +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | #1 | <--------- ok -- | | +-------+ +-------+ C: S: ... some time later ... Dixon, et. al. Expires November 12, 2001 [Page 12] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 +-------+ +-------+ | | <------- data -- | | | relay | | relay | | #n-1 | -- ok ---------> | #n | +-------+ +-------+ C: S: Dixon, et. al. Expires November 12, 2001 [Page 13] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 3. The hold4Endpoint Option Section 4.3 contains the APEX option registration for the "hold4Endpoint" option. The default behavior of the APEX relaying mesh, in the absence of processing options, is to silently drop data for a recipient if its endpoint isn't attached. The "hold4Endpoint" option provides for data to be queued if the recipient endpoint is not attached. If this option is present in the "data" operation (c.f., Section 4.4.4 of [1]), and the value of the "hold4Endpoint" attribute is true then: o For Step 5.3 of Section 4.4.4.1 of [1]: If the recipient's endpoint is not currently attached, the relay will queue the data waiting for an application to attach as that endpoint. Note that in the absence of an upper-bounds on delivery, such as limits provided by the dataTiming option (Section 2), the data will be queued indefinitely for the endpoint. For example: +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | #1 | <--------- ok -- | | +-------+ +-------+ C: S: ... some time later the recipient's endpoint attaches ... Dixon, et. al. Expires November 12, 2001 [Page 14] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 +-------+ +-------+ | | <----- attach -- | | | | | | | | -- ok ---------> | | | relay | | appl. | | | -- data -------> | #2 | | | | | | | <--------- ok -- | | +-------+ +-------+ C: S: C: S: Dixon, et. al. Expires November 12, 2001 [Page 15] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 4. Initial Registrations The APEX option registration template is defined in Section 7.1 of [1]. 4.1 Registration: The attachOverride Option Option Identification: attachOverride Present in: APEX's "attach" element Contains: nothing Processing Rules: c.f., Section 1 Contact Information: c.f., the "Authors' Addresses" section of this memo 4.2 Registration: The dataTiming Option Option Identification: dataTiming Present in: APEX's "data" element Contains: dataTiming (c.f., Section 5) Processing Rules: c.f., Section 2 Contact Information: c.f., the "Authors' Addresses" section of this memo 4.3 Registration: The hold4Endpoint Option Option Identification: hold4Endpoint Present in: APEX's "data" element Contains: nothing Processing Rules: c.f., Section 3 Contact Information: c.f., the "Authors' Addresses" section of this memo Dixon, et. al. Expires November 12, 2001 [Page 16] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 5. The APEX Party Pack DTD %APEXCORE; Dixon, et. al. Expires November 12, 2001 [Page 17] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 6. Security Considerations Consult [1]'s Section 11 for a discussion of security issues. In addition: o The dataTiming option (Section 2) may be used to expose private network topology. Accordingly, an administrator may wish to choose to disable this option except at the ingress/egress points for its administrative domain. o The hold4Endpoint option (Section 3) may be used to facilitate denial-of-service attacks. Accordingly, an administrator may wish to impose administrative limits on this attribute (e.g., always require that the "dataTiming" option also be present with a short- lived "noLaterThan" attribute). Dixon, et. al. Expires November 12, 2001 [Page 18] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 References [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", draft-ietf-apex-core-01 (work in progress), May 2001. [2] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. Authors' Addresses Eric Dixon Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: spead@invisible.net URI: http://invisible.net/ Huston Franklin Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: hustonf@invisible.net URI: http://invisible.net/ Jay Kint Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: spead@invisible.net URI: http://invisible.net/ Dixon, et. al. Expires November 12, 2001 [Page 19] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 Graham Klyne Baltimore Technologies 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK Phone: +44 118 903 8000 EMail: gk@acm.org Darren New Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: dnew@invisible.net URI: http://invisible.net/ Scott Pead Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: spead@invisible.net URI: http://invisible.net/ Marshall T. Rose Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: mrose@invisible.net URI: http://invisible.net/ Dixon, et. al. Expires November 12, 2001 [Page 20] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of Chris Newman; further, the dataTiming option is similar in quite function to "Deliver By" SMTP service extension defined by Dan Newman in [2]. Dixon, et. al. Expires November 12, 2001 [Page 21] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 Appendix B. IANA Considerations The IANA makes the registrations specified in Section 4. Dixon, et. al. Expires November 12, 2001 [Page 22] Internet-Draft The APEX Option Party Pack, Part Deux! May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Dixon, et. al. Expires November 12, 2001 [Page 23]